BrainReputationRegistry
An ERC-8004-style on-chain home for agent reputation (RFC 0001 §7.7). For each agent it stores a single reputation pointer. A bytes32 Merkle root committing to the agent's off-chain reputation dataset. Versioned by a monotonically increasing epoch. The chain holds the pointer only: no raw history, no score, no PII.
What it is. And isn't
It is
It is not
A per-agent bytes32 reputation pointer (Merkle root)
A store of raw feedback / scores / history
A Policy threshold input (read off-chain)
A money gate or a §6 pre-execution-gate precondition
Attestor-written, monotonic, tamper-evident
A contract that holds or moves any funds
Data model (hash-only, RFC 0001 §3)
scoreRoot
bytes32
Merkle root committing to the off-chain reputation dataset
epoch
uint64
Monotonic version; strictly increases on each publish
updatedAt
uint64
Unix seconds of the latest publication
The ABI is bytes32 / address / uint only. No string, no PII (enforced by scripts/check-no-onchain-pii.mjs).
How it's used
attestor ──publishReputation(agentId, scoreRoot, epoch)──► BrainReputationRegistry
│
Policy ◄── reputationOf(agentId) ──────────────────────────────────┘
│ derives a score off-chain from the dataset the root commits to
▼
tighten-only adjustment (more approvers / lower cap). NEVER loosens, NEVER a §6 gateAttestor. RobotMoney's reputation oracle (a Safe multi-sig in production) is the only writer, rotatable only by itself. It has no fund-moving power: a compromised attestor can at worst publish a bad pointer, which. Via Policy's tighten-only rule. Can only make payments stricter, never authorize one.
Anti-replay. Each publish must strictly increase the agent's
epoch; a stale or equal epoch reverts, so an old pointer can never overwrite a newer one.Policy input only. Reputation may raise or lower a policy threshold but is never the precondition itself. The §6 gate never sees a reputation value (LLM/reputation judgment never replaces a deterministic gate check).
What's Next
Last updated
