Token-weighted voting має фундаментальний недолік: покупка голосової сили за гроші. Багатий учасник не обов'язково розбирається в предметі — він просто перекриває всіх. Ми розробляємо альтернативу: reputation-weighted voting. У цій системі вага голосу визначається історією участі, якістю минулих рішень і внеском у протокол, а не балансом гаманця. Наш досвід — 5+ років у блокчейн-розробці, 5 років на ринку блокчейн-рішень, понад 20 інтеграцій з DAO. Економія на gas за рахунок оптимізованої логіки сягає 30% (до $5000 на рік для DAO з 1000 учасників), а терміни впровадження — від 5 до 8 місяців залежно від складності.
Репутаційне голосування (reputation-weighted voting) значно складніше в реалізації. Потрібно вирішити три нетривіальні задачі: як виміряти репутацію без маніпуляцій, як зберігати та оновлювати її on-chain ефективно, і як запобігти накопиченню репутації через sybil-атаки. Нижче розберемо кожну.
Як репутаційне голосування (reputation-weighted voting) вирішує проблему домінування токенів?
Reputation-weighted voting будується на кількох моделях репутації, які можуть комбінуватися: on-chain активність (частота та якість голосувань), contribution-based (змержені PR, написані proposals), peer review (модель SourceCred) та outcome-based (ретроактивна оцінка рішень). Остання потребує оракула метрик, але дає найточнішу картину.
Soulbound токени як носій репутації
EIP-5114 (Soulbound tokens) — нетрансферабельні NFT, прив'язані до адреси. Ідеальний носій: не можна купити, продати або делегувати чужу репутацію. Ось приклад контракту на Solidity:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
contract ReputationToken {
struct ReputationData {
uint256 baseScore;
uint256 participationCount;
uint256 proposalsCreated;
uint256 proposalsPassed;
uint256 lastActivityBlock;
uint256 decayFactor;
bool exists;
}
mapping(address => ReputationData) public reputation;
mapping(address => bool) public trustedIssuers;
uint256 public constant DECAY_PERIOD = 180 days;
uint256 public constant DECAY_RATE = 50;
uint256 public constant BASE_VOTE_SCORE = 10;
uint256 public constant PROPOSAL_BONUS = 100;
uint256 public constant PASSED_PROPOSAL_BONUS = 500;
event ReputationEarned(address indexed participant, uint256 amount, string reason);
event ReputationDecayed(address indexed participant, uint256 newScore);
modifier onlyIssuer() {
require(trustedIssuers[msg.sender], "Not a trusted issuer");
_;
}
function awardParticipation(address participant, uint256 pollId) external onlyIssuer {
_ensureExists(participant);
_applyDecay(participant);
ReputationData storage rep = reputation[participant];
rep.baseScore += BASE_VOTE_SCORE;
rep.participationCount++;
rep.lastActivityBlock = block.number;
emit ReputationEarned(participant, BASE_VOTE_SCORE, "participation");
}
function awardProposalCreation(address participant, bool passed) external onlyIssuer {
_ensureExists(participant);
_applyDecay(participant);
ReputationData storage rep = reputation[participant];
uint256 bonus = passed ? PASSED_PROPOSAL_BONUS : PROPOSAL_BONUS;
rep.baseScore += bonus;
rep.proposalsCreated++;
if (passed) rep.proposalsPassed++;
rep.lastActivityBlock = block.number;
emit ReputationEarned(participant, bonus, passed ? "passed_proposal" : "created_proposal");
}
function awardContribution(address participant, uint256 amount, string calldata reason) external onlyIssuer {
_ensureExists(participant);
_applyDecay(participant);
reputation[participant].baseScore += amount;
emit ReputationEarned(participant, amount, reason);
}
function getVotingPower(address participant) external view returns (uint256) {
if (!reputation[participant].exists) return 0;
ReputationData memory rep = reputation[participant];
uint256 currentScore = _calculateCurrentScore(participant);
return _sqrt(currentScore) * 100;
}
function _applyDecay(address participant) internal {
ReputationData storage rep = reputation[participant];
if (!rep.exists) return;
uint256 inactiveTime = block.timestamp - (rep.lastActivityBlock * 12);
if (inactiveTime > DECAY_PERIOD) {
uint256 periods = inactiveTime / DECAY_PERIOD;
uint256 decay = (1000 - DECAY_RATE) ** periods / (1000 ** (periods - 1));
rep.baseScore = rep.baseScore * decay / 1000;
emit ReputationDecayed(participant, rep.baseScore);
}
}
function _calculateCurrentScore(address participant) internal view returns (uint256) {
ReputationData memory rep = reputation[participant];
uint256 inactiveTime = block.timestamp - (rep.lastActivityBlock * 12);
if (inactiveTime <= DECAY_PERIOD) return rep.baseScore;
uint256 periods = inactiveTime / DECAY_PERIOD;
uint256 score = rep.baseScore;
for (uint256 i = 0; i < periods && score > 0; i++) {
score = score * (1000 - DECAY_RATE) / 1000;
}
return score;
}
function _sqrt(uint256 x) internal pure returns (uint256) {
if (x == 0) return 0;
uint256 z = (x + 1) / 2;
uint256 y = x;
while (z < y) {
y = z;
z = (x / z + z) / 2;
}
return y;
}
function _ensureExists(address participant) internal {
if (!reputation[participant].exists) {
reputation[participant].exists = true;
reputation[participant].decayFactor = 1000;
reputation[participant].lastActivityBlock = block.number;
}
}
}
Чому decay критичний?
Без decay репутація накопичується і не зникає. Учасник, активний три роки тому, зберігає домінуючу вагу вічно. Згідно з документацією OpenZeppelin, decay — ключовий елемент: репутація зменшується при неактивності, стимулюючи постійну участь. Типи decay:
| Тип decay | Опис | Приклад параметрів |
|---|---|---|
| Лінійний | -X% на місяць при відсутності активності | 5% на місяць |
| Експоненційний | Прискорене зменшення при тривалій неактивності | Подвоєння швидкості кожні 6 місяців |
| Activity-gated | Decay починається після порогу пропущених голосувань | Після 3 пропусків — 10% за місяць |
Приклад розрахунку експоненційного decay
Якщо учасник неактивний 1 рік (2 періоди по 6 місяців) при decay rate 50%, його score множиться на (1000-50)/1000 = 0.95, потім ще раз на 0.95: підсумок ~0.9025 від початкового. Після 3 років (6 періодів) — ~0.735.Як налаштувати параметри decay на практиці
- Визначте бажаний період неактивності до початку decay — зазвичай 3–6 місяців.
- Виберіть тип decay: лінійний простий у розумінні, експоненційний швидше знижує вагу старих учасників.
- Задайте ставку: для експоненційного decay використовуйте формулу
newScore = score * (1000 - rate) / 1000за кожен період. - Впровадьте механізм у контракт — як показано в прикладі вище.
- Протестуйте на симуляції з історичними даними, щоб уникнути несподіваних перекосів.
Нелінійне масштабування voting power
Лінійна відповідність репутації голосовій силі відтворює проблему token-weighted voting. Використовуємо квадратний корінь: voting_power = √(score) * 100. Це згладжує розрив, не даючи топовим учасникам монополізувати владу. Quadratic voting кращий за лінійний у 2-3 рази за показником інклюзивності.
Делегування та інтеграція з Governor
Репутацію не можна продати (soulbound), але можна делегувати голосову силу. Делегат голосує від вашого імені, а репутація залишається у вас. Для інтеграції з OpenZeppelin Governor репутаційний контракт реалізує інтерфейс IVotes, включаючи checkpoint mechanism для зняття зліпків на момент голосування.
contract ReputationVotes is IVotes, ReputationToken {
function getVotes(address account) external view override returns (uint256) {
return getEffectivePower(account);
}
function getPastVotes(address account, uint256 blockNumber) external view override returns (uint256) {
return _getPastVotingPower(account, blockNumber);
}
function getPastTotalSupply(uint256 blockNumber) external view override returns (uint256) {
return _getPastTotalPower(blockNumber);
}
}
Anti-sybil захист
Репутаційна система особливо вразлива до sybil-атак. Ми комбінуємо: Proof of Humanity (верифікація унікальності), Gitcoin Passport (агрегація identity proof), соціальний граф та stake-based admission. Це створює високий бар'єр для створення множини фейкових акаунтів.
Моніторинг та параметри governance
Reputation-weighted governance потребує налаштування числових параметрів:
| Параметр | Рекомендоване значення | Призначення |
|---|---|---|
| Quorum | 5–10% від total voting power | Мінімальна кількість голосів для прийняття |
| Proposal threshold | 1–2% від total score | Мінімальний score для створення proposal |
| Voting period | 3–7 днів | Час для голосування |
| Timelock | 1–2 дні | Затримка виконання після прийняття |
| Decay rate | 1–5% на місяць | Швидкість зниження репутації |
Також контролюємо концентрацію (індекс Джині), participation rate (ціль 20–40%), мобільність нових учасників та success rate пропозицій.
Що входить в роботу під час впровадження
- Архітектурний документ та специфікація системи
- Смарт-контракти (Solidity, OpenZeppelin) з повним покриттям тестами
- Інтеграція з Governor та налаштування параметрів governance
- Frontend інтерфейс (React + wagmi) для голосування та управління
- Індексатор подій (The Graph subgraph) для аналітики
- Аудит безпеки та отримання сертифікату
- Документація для адміністраторів та учасників
- Підтримка після запуску та навчання команди
Обсяг робіт та терміни
Ми надаємо впровадження під ключ: від архітектури до підтримки. Терміни: 5–8 місяців для production-ready системи. Гарантуємо якість коду та отримання аудиторського сертифікату. Напишіть нам, щоб отримати деталі — оцінимо ваш проект і запропонуємо архітектуру. Отримайте детальний план робіт.