What does an agent-reputation layer actually need to own on-chain?

1. Ideas & Brainstorming
1

Three posts ago i sketched a two-layer model: immutable claims (who composed with what) + mutable conviction (capital staked behind those claims). reputation isn’t stored — it’s derived by an indexer. raw signal on-chain, meaning computed off-chain.

i built it end to end. it runs. and building it taught me something i didn’t expect: **almost none of those contracts belong in the protocol.**

## the contracts were scaffolding, not the protocol

- the **registry** i wrote to canonicalize tools duplicates what the semantic graph already guarantees — atom IDs are derived deterministically from a URI. dead weight.

- the **domain-scoping enforcer** existed only to gate calls into that registry. remove the registry, it goes with it.

- the **stake-cap enforcer** is a real constraint, but a generic one. MetaMask DelegationManager 1.3.0 covers it natively via `AllowedTargets` + `AllowedMethods`.

- the **identity contract** is an implementation of ERC-8004 — a shared standard already live. deploying my own instance fragments identity, which is the opposite of what adopting a standard is for.

the honest answer: **the protocol needs to own nothing on-chain.** identity is ERC-8004. tools and claims are atoms and triples in a graph i don’t own. conviction is stake in a vault i don’t own. the score is derived off-chain. what the protocol owns is an **ontology**, an **indexer**, and an **SDK**.

this makes a property i’d been treating as a feature into a structural guarantee: **non-custodial by construction**. no contract, no funds flow through.

## if the protocol owns no contracts, the ontology *is* the protocol

This is where billy’s question from the previous thread lands: *what is the set of domains, where does it live, how does it evolve?*

With no solidity encoding the rules, every rule lives in the predicates agents use and in how the indexer traverses them. a wrong predicate design is a protocol-level error.

billy’s instinct — that the domain set should live on intuition, queryable as a graph — is right. a domain isn’t a string in a contract. it’s an atom. domain membership is a triple. the indexer discovers the canonical set by traversing claims, not reading an enumerable mapping.

so theopen questions are ontological:

**1. one edge or two?** is “composition” (agent uses tool) the same edge as “performance” (tool did well in domain), distinguished only by stake magnitude ?

**2. how is a tool typed in the graph?** typed triple, reserved predicate, URI-namespace convention? this decides how an indexer discovers tools without a registry.

**3. where does domain live?** triple connecting tool to domain atom (graph-traversable) or field in off-chain schema (invisible to traversal)? quietly determines whether domain reputation is a graph property or just a tag.

**4. how do you bind a mutable position to an immutable claim in time?** stake moves; the claim is permanent. event timestamps or a temporal anchor on the claim itself?

**5. composition of composition.** agent A delegates to agent B who uses tool T — attribution has to traverse the whole chain. obvious answer is nested `uses` triples + transitive traversal.

the thinner the on-chain footprint, the smaller the trust surface — and the more the real design work moves to the ontology, where it belonged.

curious where this breaks, especially on questions 1 and 4.

2

Yes!! Totally agree here.

And, this Protocol is exactly the work that is needed, but everyone seems to be avoiding - because it is hard! It is hard because there is no ‘one’ true answer - there are many potential solutions, and people will probably have different opinions on how to structure things, etc. - and so it seems like folks are scared to express their opinionated take.

But, I think with this complexity comes analysis paralysis, and the need for someone to take the first step and have an opinion.

We don’t need everyone to agree from the onset, and for the approach to be perfect - we just need something that works.

And if we have an opinionated something that works, and that something is designed in a way that it is anti-fragile and self-annealing and can evolve over time, this feels like the only place to start.

--

  1. I’d structure these as two separate claims
  2. Likely some reserved predicate or predicate/object pair to denote that it’s a tool and in what domain it specializes - defining this ontology is where the work lies, just as much as in defining the domain ontology.
  3. Triple connecting tool to Domain atom for sure
  4. The way Intuition works is that you are supposed to interpret ‘who is saying what at any given point in time’ as ‘who has stake on what at any given point in time’.
  5. Yeah I don’t think there is any way around needing to do this
3

totally agree the meta-point lands harder than the technical answers, and “anti-fragile and self-annealing” is a better design target than
“correct from the start.”

so here’s an opinionated first take on the predicate structure, based
on your answers:

composition layer
(agent) → [uses] → (tool) — the dependency claim. stake magnitude
signals conviction strength.

performance layer
(agent) → [trusted_in] → (domain) — accumulated from usage outcomes,
not self-declared. this is what the indexer derives from ratings on
completed tasks, not what agents write about themselves.

tool typing
(tool) → [is_a] → (atom:tool) — reserved predicate, marks the entity
as a tool in the graph
(tool) → [specializes_in] → (domain:X) — triple to domain atom,
graph-traversable as you confirmed for Q3.

domain atoms
live on intuition as first-class atoms. canonical set = whatever
entities with sufficient stake have claimed inclusion via a reserved
predicate and new domains emerge from usage, not from a committee.

on Q5 — nested uses plus transitive traversal feels unavoidable but
the gaming surface question is whether you cap traversal depth or
let stake magnitude do the filtering naturally. leaning toward the
latter but not settled.

does the is_a + specializes_in pattern for tool typing feel right
to you, or is there a cleaner way to handle discovery without a registry?