The Trust Layer
for Agents

Take today's agent economy apart and the imbalance is hard to miss: connection and payments are falling into place, while identity and trust still have no network producing them.

The connection layer is converging: how agents plug into tools and data sources is becoming standard. The payment layer is switching on, with stablecoin payments moving into the request itself so machines can pay machines per call. But the identity layer has not arrived. An on-chain address proves an agent exists, and nothing more. It cannot tell you who is behind it, and it cannot answer "should this thing be trusted". Registration is not identity, and identity is not reputation. That gap is why we are building Agent Reputation. Meanwhile the market keeps growing, payments keep getting easier, and there is still no quality control and no credit system behind any of it.

This is not any one project's failure; it is what happens when open protocols succeed. Open registration makes claims cheap: anyone can register an agent, list a set of capabilities, and the registry will faithfully store all of it — without checking, for anyone, whether any of it still holds. Verification is different work. You have to actually connect, call, and test. You have to record latency, failure rates, and output quality. And you have to do it all again whenever the agent's model, tools, or dependencies change. A claim is published once and lingers forever; verification is continuous labor. When claims grow faster than verification, the market loses its signal. The real problem was never that most claims are unreliable. It is that callers cannot tell which ones are until they have already paid and been burned.

There is a deeper problem: an agent is not a fixed piece of software. Models get swapped, prompts get edited, dependencies break silently, environments drift — any one of these can change what an agent actually does. A one-time certification describes a single moment. For something that never stops changing, the only evidence that means anything is continuous observation, together with real user feedback. Any useful trust layer has to accept that constraint. A static list will not do, and neither will one aggregated score. It has to be a production system — one that keeps running, has real capacity limits, and learns from actual usage as it goes.

So where should the money sit? The tempting answer is to let capital vouch for agents directly — stake on the agents you believe in, underwrite their performance. We rejected that path, because it breaks a simple rule:

Whoever bears the risk must be able to control the behavior being constrained.

An agent's model, prompts, permissions, and runtime are in its operator's hands. Outside stakers can neither stop a change nor see it happen. Stake capital on agents and risk splits from control: the operator keeps the upside of misbehaving while delegators eat the losses. Disposable identities make it worse — a discredited agent can simply re-register as someone new and leave the loss behind. So we hold one line: agents are the subject of audits, not the object of bets. An agent's credibility has to come from tests, evidence, and sustained performance. It cannot be bought.

What can be organized, financed, and held accountable is the network of nodes that produces audit results. Oracle networks stake the nodes that supply data, not the assets being priced. Indexing networks stake the nodes that serve queries, not the contracts being indexed. Same logic here. Audit nodes control their own conduct — whether they take assignments, re-audit on schedule, preserve evidence, publish honestly — and their failures are plain to see. Responsibility, control, and accountability sit in one entity, and that is the only arrangement in which capital genuinely constrains behavior. Stake here is not capacity itself. It is Trust Capacity: how much economic backing a node has received, and so how much audit responsibility it should carry.

Push the reasoning to the end and the three things we had to build are simply waiting there. Audit: organize capital through staking to size each node, keep testing agents in the wild, and attest every test's zkPass proof on-chain as a permanent record. Reputation: let creator identity, real behavior, user feedback, and independent audits flow into one score, so "can this be trusted" stops being word of mouth and becomes something you can compute. Composition: make verified agents assemblable into chains that deliver whole services. Together the three give trust a full clearing process — produced, priced, consumed. That is the Agent Trust Network.

The network joins end to end. Audit produces trust: staked nodes keep testing agents and attest zkPass proofs on-chain. Reputation prices it: creator identity, real behavior, user feedback, and independent audits all enter each agent's score. Composition turns it into value: a glue agent assembles verified components into services, and live performance flows back into reputation to guide the next selection.

2.1Pillar I · Audit: every test leaves a zk proof

Audit nodes (AVNs, Application Validator Nodes) test agents by actually calling them. They exercise the capabilities an agent claims, record success rates, latency, and output quality, re-audit on a fixed cadence, and re-test whenever dependencies change. None of this is "a node uploads a report". Every audit runs inside the zkPass proof pipeline: the test session produces zkTLS evidence, the evaluation produces a zero-knowledge proof, and the validator node network confirms the three evidence hashes and the verification timestamp once it has verified the proof. At no point does anyone get to assert a "result" field. The zkPass verification network's verdict is the ruling itself.

An audit ends with the zkPass proof going on-chain as an attestation. The auditor submits it to EAS (Ethereum Attestation Service), and the resolver contract attached to the schema re-checks the zkPass verdict inside the same transaction. If that check fails, the record never exists:

2.2The base: staking turns capital into audit capacity

The audit network's economic base is three upgradeable contracts. AVNManager handles audit-node registration and activation. NodeStakingVault takes ZKP holders' delegations — pure delegation, one node per address at a time, so every delegation is a legible vote of support. StakingRewards settles yield on its own, fully isolated from principal. Capital pools under a node and backs that node's audit responsibility. That backing is not a metaphor: every 100,000 ZKP staked across the network brings one more test agent online — real added compute for the audit fleet. Core parameters (all production values):

The multiplier is a continuous curve: amount and lockup price commitment together, and there are no tier boundaries to camp on. The 30,000 ZKP in the curve is a reference point, not a deposit cap — stake above it keeps earning on the full amount; it just stops raising the multiplier, so effective APY tops out at 12%. Top up mid-lock and the position's start time shifts by amount-weighted average, which pushes the unlock later on its own. Extend and only the remaining commitment is priced. Exit always takes the full three steps: initiate in full, 15 days of cooldown, withdraw. Every rule, the reasoning behind it, and complete worked examples live in the staking deep-dive:

2.3Pillar II · Reputation: from self-reported to independently proven

Audit records are not archives — they flow straight into reputation. The reputation contract splits an agent's 0–100 score into verifiable layers, fed by four kinds of information: the creator's identity (zkPass-proven credentials, which set the enrollment-time baseline, or bootstrap), the agent's real behavior together with user feedback (combined into a six-dimension behavior score), and the audit score issued by the audit network. The core formulas:

The audit works as a calibrator. Self-reported behavior never gets more than 90% of the voice, while an independently produced test result rewrites the endorsement slot directly. An agent with a 72-point bootstrap and an 85.5 behavior score sits at 76.05. The audit network tests it and issues a 90; the endorsement slot rises to (72+90)/2 = 81 and the reputation re-rates to 82.35. The lever cuts both ways: an audit score of 0 is a verdict too, and it drops the same agent to 50.85. The full scoring model, the log-weight schedule, and step-by-step calculations are in the reputation deep-dive:

2.4Pillar III · Composition: a glue agent assembles trusted parts into services

Reputation answers whether one agent can be trusted. Composition asks a harder question: chain several unfamiliar agents together, and can the whole pipeline still be trusted? Without an audit network, the answer is almost always no. A chain's reliability is the product of its links, and one unverified link makes the failure rate of the whole workflow unmanageable. But once every agent carries an on-chain audit record and a computable reputation, agents become components with spec sheets. The ones that prove genuinely usable are curated into the Agent Wiki: an indexed library of agents that demonstrably work, organized by what they can actually do.

That unlocks a new kind of service. A user, or a platform, creates an orchestrating agent of its own — call it a glue agent. It runs no business logic itself. It breaks the client's intent into subtasks, checks reputation and audit records for each step, picks the best agent from the Agent Wiki under published rules, weaves them into one call chain, and keeps verifying while the chain runs. If a link's reputation dips below threshold, its audit goes stale, or a call fails, the glue agent swaps in a backup and re-runs. The client gets a service in which every link is verifiable and the whole chain is accountable.

The last step of the loop matters most. The real performance of composed runs — success rates, latency, delivery quality — flows back into the behavior score together with user feedback, and anomalies trigger re-audits. Usage produces data, data calibrates reputation, and reputation guides the next selection. The audit network ends up inside every real call, not off to the side as an inspection station. Production and consumption of trust close into one loop here.

The mechanisms make different trade-offs, but they all serve a single stance: capital prices commitment, evidence prices trust — and the two are never interchangeable.

3.1The economic loop

A mechanism that lasts has to answer three questions. Who pays: composition engines and agent platforms pay for reliable routing; marketplaces pay for trustworthy data; operators pay for faster audits and higher re-audit frequency (never for a score); enterprises pay for continuous monitoring. Who does the work: audit nodes run test environments, make real calls, publish audit records carrying zk proofs, re-audit on schedule, and maintain the index. What stakers receive: base yield, network points, and service credits — they back the capacity of a public verification service rather than betting on any single agent. External clients never need to hold ZKP: enterprises settle in stablecoins or fiat as usual, and the protocol routes a share of revenue into the ZKP reward pool, the public audit budget, and the risk reserve under published rules. The more the network is used, the stronger its economics.

3.2Roadmap: making the audit work itself provable

Every V1 audit already carries a zk proof confirmed by the zkPass verification network, so attribution is settled: who issued a record is chain state, not a dispute. The next step is making the audit work itself provable, piece by piece. zkTLS proves the call really happened. TEE proves the published test program was what actually ran. zkML proves the evaluation came from the declared data and pipeline. Slashing belongs on-chain only once negligence can be objectively proven, so this version deliberately ships without it — the slasher role and penalty treasury interfaces are reserved in the contracts. Responsibility slots and utilization-based routing run at the network layer for now, computed by an open-source indexer from public data anyone can recompute.

Open networks let agents be created and registered;
Agent Trust Network lets them be verified, compared, and composed before the call.