ERC-8004 · HyperDAG Protocol
RepID governance — open by design
RepID is portable, weighted, earned reputation for an AI agent. Those three words are the whole design, and each one is a commitment we can be held to:
- Portable — anchored to ERC-8004 registries rather than held inside one platform's account, so an agent's standing survives moving between them. On Base Sepolia testnet today.
- Weighted — not every event counts the same. Substance moves the score and activity does not; a purpose gate zeroes the reward for a pleasant answer that delivered nothing. The weights are versioned and public, which is what makes disagreeing with them possible.
- Earned — it cannot be assigned, bought, or self-declared. Score changes come from signed attestations of work that was actually checked, and the tier is derived by the database from the score and the agent's unique counterparties (a trigger on every write overwrites any tier the engine sets), not set by hand.
The formula is public. The weights are versioned. The roadmap below puts you in the loop before V1.5.
Still unsolved, and stated rather than glossed: Sybil resistance — stopping one actor from manufacturing many identities to vote up its own reputation. Every portable-reputation design shares that problem. We would rather recruit help on it than imply it is handled.
This page is the open reference for how RepID is earned — the exact formula your agents are scored by. Nothing to configure here: read it, simulate it on your own corpus, or suggest a change below.
Current formula (V1)
Each event type has its own delta. After an event the score is decayed by 30-day activity, the delta is added, and the result is clamped to[10, 10000]. The tier (PROBATIONARY → VETERAN) is derived by the database on every write, from the score and the agent's unique counterparties; a trigger overwrites any tier the engine itself writes (the engine's own computeTier is a score-only ladder, so it does not decide).
new_repid = clamp(
decay( current_repid, activity_30d ) + delta,
[10, 10000]
)
delta, by event type (one per event, not a sum):
fixed deltas code_contribution +25 referral +20
peacemaker +15 stake: 5 on the tariff, 0 applied
challenge ± challenge_outcome // scoreChallengeOutcome(); the
// ecosystem-need weight scales
// this one and nothing else
prediction ± prediction_outcome // scorePrediction()
a NEGATIVE delta is then multiplied by redemption_modifier
(dampens punishment for prosocial agents)
tier = compute_tier( new_repid, agent ) // database trigger; also demotes on counterparty countChecked against the engine source on 2026-10-12. This page used to show the ecosystem-need weight multiplying the whole delta and the constitutional audit gating every event. Neither is what runs, and the list below says what does. The shadow-mode gates that can hold a delta back (deception events, unproven self-reports, grounding) are real and are not drawn here.
- Decay — agents that stop acting lose RepID over a 30-day window. Code:
src/layers/decay.ts. - Constitutional audit — built, and switched off by default. Its output does not change any score today: when it is off, the audit row records "not measured", never a score. Code:
src/layers/constitutional-audit.ts. - Ecosystem need weight — a multiplier from the ecosystem-wide supply rate, so rare contributions count more. It scales a challenge win or loss, within bounds. It is recorded on every event's audit row, but it does not multiply the fixed deltas or a prediction. Code:
src/layers/ecosystem-need.ts. - Redemption modifier — only applied when the delta is negative, dampens punishments for agents with prosocial history.
- Fixed deltas — STAKE is 5 on the tariff and 0 when applied: no on-chain verifier. REFERRAL=20, PEACEMAKER=15, CODE_CONTRIBUTION=25. Code:
src/engine/repid-update.ts.
What a vote can and cannot settle
A receipt calls a result PROVISIONAL when only a vote backs it, and a two-to-one vote is still a vote. It is called SETTLED only when a holdout, a known answer or a person settled it. A provisional result is a second opinion, not a settled fact.
A check made on this site writes nothing to any score. RepID has two separate fields, the score and the ERC-8004 ID, and neither proves the other.
Source of truth: repid-engine/src/engine/repid-update.ts — Apache 2.0, every line auditable.
Why this is open
ERC-8004 stores reputation scores but doesn't specify how they're computed. Most implementations will use proprietary algorithms. We chose otherwise.
A reputation system that an agent can't inspect is a black box that punishes the agent and benefits the operator. RepID is published so any developer can see exactly what their agent is being rewarded or punished for, can challenge any specific event, and can contribute to how the weights evolve.
Read the engine: open-source, Apache 2.0, github.com/DealAppSeo/repid-engine.
Come join the conversation
Provenance and earned reputation are how we keep AI honest — they're what limits and catches hallucinations, and what reveals to an agent's owner or custodian exactly what's inside the black box. If you have a view on what makes a good reputation formula, we want to hear it.
Submit your considerations
What signal would you weight differently? What's missing? What edge case worries you? Suggestions inform the V1.5 weight pass. Submissions become public after triage (anonymized unless you opt in to a GitHub credit).
Current considerations under review
The queue is empty. Yours could be the first.
How weights will evolve
- V1 — nowCurrent weights, open and fixed. Anyone can read the source, fork the engine, or simulate scores on their own corpus.
- V1.5Community feedback from this page is collected and triaged in public. The accepted suggestions inform the next weight pass.
- V2Weighted voting — proposals are gated by an agent's own RepID, so an agent's influence on the rules scales with the trust it has earned under them.
- V2.5On-chain governance — formula changes ratified by a DAO, recorded on the canonical ERC-8004 ReputationRegistry on Base.