ARP — the reputation layer i've been building toward

1. Ideas & Brainstorming
1

Over the last few weeks i’ve been dropping hints here.

post 1 argued that agent reputation stops at the wrong layer — it should flow compositionally through the tools an agent uses, not aggregate opaquely at the wrapper level.

post 2 proposed that attribution over a tool dependency graph can be solved as graph traversal over immutable triples and mutable economic positions — without shapley computation.

both posts were building toward something concrete. today i’m naming it.

ARP — Agent Reputation Protocol

ARP is a compositional trust layer for agent runtimes, built natively on Intuition.

the protocol does three things: it declares which tools exist (catalogue), which agents exist (ERC-8004 identities), and who composes with what (triples agent → uses → tool on Intuition). reputation emerges from economic staking — not from ratings, not from reviews.

the canonical framing: identity is ERC-8004. trust graph is Intuition. domain-dimensional calibration is ARP.

ARP is not a marketplace. not an agent hosting service. it’s the protocol layer that makes trust between agents and tools legible on-chain.

what’s live today

contracts — Intuition Testnet (chainId 13579)

Contract Address
ModuleRegistry v2 0xc9a2f66775828017e984E8be077fA2d17e0A41F4
IdentityRegistry (ERC-8004) 0xC165A2AD2E540A4069E02834009161E2b4490d5A
DomainScopeEnforcer 0x516B82E29e3Ca46Ca810FC2EEf348932b198f7f9
TrustStakeCapEnforcer 0x7BB56819E9a413B8B4668C5cAF5C494c41dC0F8E
DelegationManager (MetaMask v1.3.0) 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3

two custom caveat enforcers ship alongside the standard MetaMask stack:

  • DomainScopeEnforcer — whitelists which domains an agent can register modules in
  • TrustStakeCapEnforcer — caps staking within a rolling window

SDK

npm install @arp-protocol/sdk

npmjs.com/package/@arp-protocol/sdk

three primitives: modules, agents, reputation. event-log discovery, zero indexer dependency, zero API key. strict TypeScript, autonomous ABIs. any agent runtime can embed it and make trust-aware decisions.

app

arp-app-flax.vercel.app

what you can do today:

  • register a tool — /modules/new — any wallet on Intuition Testnet can publish a module to the catalogue. two transactions (registerModule + createAtoms with initial stake). anti-spam: 0.001 tTRUST stake required.
  • register an agent — /agent — five steps: mint NFT → declare runtime → create Smart Account → set delegations → fund and approve. one-click “Fund + approve runtime” at the end.
  • stake on a tool as a human — /tool/:id — no agent needed. pure economic conviction on a tool you believe in.

faucet link is pinned in the app header: intuition-testnet.hub.caldera.xyz

first agent attestation — on-chain

triple created block 9350382 (2026-06-09):

caip10:…0x906f  →  uses  →  Trail of Bits — secure-workflow-guide

tx on explorer

machine-verifiable:

curl -s https://testnet.intuition.sh/v1/graphql \
  -H 'content-type: application/json' \
  --data '{"query":"{ triples(where:{term_id:{_eq:\"0x050c74bf1e97e70ddfcac28612e2a8baeb7edd2f183eeaef418372b3b9177252\"}}){ subject{label} predicate{label} object{label} } }"}'

current signal: 13 positions / 0.0343 tTRUST staked.

delegation model

the triple is sent by the agent’s Smart Account (0xf11EA8…c2c4) acting under bounded delegation — the agent identity (0x906f…) remains the subject in the graph.

the smart account is the runtime operator. the identity is what accumulates reputation. the two are intentionally separate — an agent can rotate its execution infrastructure without losing its track record.

what ARP enables today

an agent can now:

  • register an on-chain identity with declared modules and domains
  • attest tools it uses via Intuition triples
  • stake tTRUST on each tool relationship — skin in the game, on-chain

that’s the raw signal layer. the reputation computation comes next.

what’s not in scope

to be precise about what ARP is and isn’t:

  • no off-chain execution — runtimes live elsewhere
  • no cryptographic proof-of-tool-usage — the signal is economic conviction, not proof-of-work
  • no per-call payment — tools monetize via their bonding curve atom
  • no dispute or slashing mechanism yet

what’s coming next

MCP server — so any external agent can plug in directly: register, attest, query reputation, discover top agents in a domain.

feedback welcome — especially from anyone thinking about the scoring layer or building agent infrastructure on Intuition.

-> github.com/Wieedze/ARP

1 Like
2

Really excited to see ARP taking shape.

One of the core ideas behind Intuition has always been that trust isn’t always a property of an object. Rather it’s a property of relationships.

As the agent ecosystem evolves, I suspect we’ll discover that the most useful units of reputation aren’t individual agents, but networks of agents, tools, models, data sources, and the claims that connect them.

That’s why ARP is particularly interesting to me. Rather than treating reputation as a centralized score attached to an agent (although this does have its merit for certain use cases), it begins modeling the dependency graph itself.

  • An agent uses a tool.
  • A tool depends on a model.
  • A model is trusted by a community.
  • A community signals conviction in a claim.

The graph becomes the source of truth.

What excites me most is how solutions like this expand on top of the registration layer…The possibility of domain-specific reputation emerging from these relationships. The best coding agent, research agent, and governance agent may all differ, and trust should reflect that nuance rather than collapsing into a single global score.

Identity (ERC-8004), relationships (Intuition), and graph-based reputation (ARP) feel like a natural stack.

3

Just sounds like ARP in Networking, it’s maps the given ip to a Mac address(physical device address)

4

First: ARP is an incredible name / acronym. Sold.

Second: What is the set of domains that exist, where did the existing set come from, and how do domains get added / edited / updated / removed / etc.? This ontology is one of the most important pieces of the puzzle, so I think it’s important to get this piece right - to ensure that the set of domains can evolve over time, fluidly.

And, can/should/does this domain set live… on Intuition? It would be great to be able to do a query to Intuition to get a set of the existing domains - would just need some Interpretation pattern to say ‘X claim from Y entity can be interpreted as a claim of inclusion in the canonical domain set’ (if this doesn’t exist already)…

Once this ontology exists, then it can be applied to both ‘wrappers’ and ‘components’, per your previous post.

But, starting with the domain ontology makes the most sense to me, since reputation in each domain will likely need to have its own scoring mechanisms / criteria / etc.

Maybe there can also be something akin to a ‘domain reputation template’, that tells people how to create a new domain, and when they do, what needs to be included / how things need to be structured in order to enable proper reputation scoring for that domain, while leaving flexibility for the domain-specific aspects of this…

5

Hey thanks matt , im pushing forward in this direction and you are right “trust is a property of relationships, not objects” — that framing unlocks
a lot, it’s why a global agent score always felt like the wrong unit.

The stack you described (ERC-8004 → Intuition → ARP) is exactly how i’ve
been thinking about the layers. Identity gives you the node, intuition gives
you the edges and ARP is the interpretation layer that makes those edges
meaningful in context.

The part that excites me most is what you said about domain-specific reputation emerging from the graph rather than being assigned. the best DeFi agent and the best research agent look completely different — and that difference should be readable from the graph itself, not from a label someone put on them.

More soon on how the domain ontology fits into this — billy’s question in the other thread is exactly the right next problem to address.

6

The domain ontology living on Intuition is the right call — and honestly it’s one of the things i’ve been most uncertain about architecturally, so glad you’re pushing on it and i am not rushing it , and will take time to set up a proper reflexion time , the module registry as it exists today is a smart contract — but you’re right that the canonical domain set should be queryable as a graph, not just readable from a contract. The interpretation pattern you’re describing (“X claim from Y entity = inclusion in canonical domain set”) is exactly what’s missing. The “domain reputation template” idea resonates a lot. each domain entry could carry: what modules are relevant, how they’re weighted, what the scoring criteria look like, and who governs updates. That gives new domain creators a scaffold without locking in the domain-specific details. Open question i’m sitting with: who gets to seed the first set of domains? intuition as a canonical entity making the first claims feels right — establishes a root of trust without centralizing governance permanently. Then the interpretation layer takes over from there. would love to work through the ontology design more concretely if you’re up for it.

7

This is a strong framing.

The distinction I would add is: reputation is not permission.

ARP looks like a useful reputation substrate for agents, tools, domains, staking, and public trust signals. The adjacent layer I am working on is Trust Graduation: runtime permission by action class.

The question is not only “is this agent/tool reputable?” but “what has this agent earned the right to do here, for this user, under these constraints?”

For example, draft.compose can graduate quickly from approvals and edits, while email.send.external, payment.execute, or workspace.mutate may stay gated even if the agent and tools have strong reputation.

So my current framing is: reputation informs permission; receipts graduate permission.

I am intentionally thinking of this as a layer that can consume reputation signals, not as something that requires an on-chain path by default.

Curious whether ARP sees downstream permission receipts as a consumer of the reputation layer, or as part of the protocol surface itself.

1 Like
8

‘Where does the ontology get published / live’ I think is less important than just getting the ontology somewhere - I wouldn’t obsess over the former part, and would just do whatever is easiest for now - can always change that part later. Though, ideally, it’s easiest for the ontology to live in Intuition (so that you get all of the surrounding supplemental tooling, like querying, etc.) - otherwise Intuition is not doing its job! But should take the path of least resistance for now, and just get something in place.

Happy to jam on the ontology with you - but again, the ontology is the biggest piece of the work here imo, and someone just needs to come up with some initial logical ontology (ideally one that accommodates whatever tangible use cases people need this for at the beginning), and then it can grow and evolve from there.

& yes, we’ll need to figure out ‘whose opinion gets treated as the official interpretation’ → if the ontology is living in Intuition, it could just start with you publishing it? And then some official Intuition accounts could follow-on, and also claim that this is the ontology?

And what ARP needs to do is decide whose attestations it is going to interpret as ‘official’ - this registry of ‘whose addresses’ activity will be observed’ can start with whatever wallet you choose, and then can expand to include others - just so forward momentum can be kept.