Cover photo

Agent Accountability On-Chain

A Reputation Primitive for Autonomous AI Agents in DeFi

Yelden Protocol · February 2026
github.com/plongen/yelden-protocol


Abstract

Autonomous AI agents are increasingly executing critical operations in DeFi protocols — liquidations, rebalancing, yield optimization, and governance participation. Yet no standard exists for verifying agent reliability on-chain. Protocols trust an address. That is the entire accountability model.

This paper proposes AIAgentRegistry — a composable Solidity primitive that gives autonomous agents a verifiable on-chain identity, a performance-based reputation score updated by a decentralized oracle network, and economic accountability through a deflationary staking mechanism. Agents that perform well pay zero fees. Agents that underperform self-eliminate through fee burn. Malicious agents are slashed and permanently banned.

The registry is designed as an open standard: any DeFi protocol can query isEligible(agent) in three lines of Solidity, creating a shared reputation layer rather than every protocol reinventing its own whitelist.

Current status: AIAgentRegistry v3 is complete — 69 tests passing, Certora 7/7, Echidna 3/3, mutation 100%. The ZKVerifier Groth16 circuit is compiled and live — 532 constraints, 198 total tests passing across the full protocol. This is not a proposal. It is running code.


1. The Problem: Trustless Systems Trusting Blindly

DeFi is built on the premise of eliminating trust. Smart contracts replace intermediaries. Rules are encoded in code. Outcomes are deterministic and verifiable.

Yet when it comes to the agents that execute within these systems, the trust model collapses entirely.

A keeper maintaining a lending protocol's health is just an address. A yield optimizer executing rebalancing strategies is just an address. A liquidation bot protecting collateral ratios is just an address. If that address misbehaves — front-running liquidations, failing to execute during congestion, or actively attacking the protocol — there is no on-chain mechanism to record this, penalize it, or prevent the same address from participating again under a different identity.

Today: Protocol delegates operation to agent → Agent misbehaves → Protocol has no recourse → Agent creates new address → Cycle repeats.

The AI agent market compounds this problem. Autonolas, Virtuals Protocol, and ai16z are deploying increasingly autonomous agents into production DeFi environments. These agents hold assets, execute transactions, and make decisions with real economic consequences — all without any shared accountability infrastructure.

The absence of this infrastructure is not a philosophical problem. It is an engineering problem with a tractable solution.


2. The Primitive: AIAgentRegistry.sol

AIAgentRegistry is a single Solidity contract that any DeFi protocol can integrate. It provides three things: verifiable identity, performance-based reputation, and economic accountability.

2.1 Agent Lifecycle

Registration is permissionless. Any Ethereum address can register as an agent by staking a minimum of 50 YLD tokens. Approval transitions the agent to ACTIVE status with an initial score of 300, set by a Chainlink Decentralized Oracle Network after off-chain validation.

State Transition

Condition

NONE → PENDING

registerAgent() + stake ≥ 50 YLD

PENDING → ACTIVE

approveAgent() by SCORER_ROLE (DON)

ACTIVE → ACTIVE

slashAgent(WARNING) — 10% burned

ACTIVE → PENDING

slashAgent(SUSPENSION) — 50% burned

ACTIVE/PENDING → BANNED

slashAgent(BAN) — 100% burned

PENDING → NONE

voluntaryExit() — stake returned if fee origin

Exit distinction: An agent who exits after fee-based stake reduction recovers their remainder. An agent who exits after a slash-based reduction loses everything. Economic punishment follows the agent, not just the action.

2.2 Score Model

Score is a number from 0 to 1000 that represents real performance history — never capital. An agent cannot buy a higher score by staking more tokens. Score starts at 300 on approval and grows exclusively through validated performance data submitted by the oracle network.

The threshold for bonus eligibility is 500. Protocols that integrate the registry can set their own thresholds depending on the criticality of the operation being delegated.

2.3 Subscription Stake: Deflationary by Design

Every active agent pays a monthly fee in YLD. The fee is inversely proportional to score:

fee = monthlyFee × (1000 − score) / 1000

An agent with score 1000 pays zero. An agent with score 500 pays half the maximum fee. An agent with score 0 pays the full fee every month. All fees are burned — sent to 0x000...dead — reducing YLD supply and creating continuous deflation proportional to the number of underperforming agents in the registry.

This mechanism creates a self-cleaning system. Agents that perform poorly cannot sustain participation indefinitely. The protocol naturally selects for quality without requiring active governance intervention.

2.4 Slashing: Economic Punishment for Bad Behavior

When the oracle network or DAO governance identifies malicious behavior, the SLASHER_ROLE can execute one of three slash levels:

Level

Stake Burned

Status After

Use Case

WARNING

10%

ACTIVE

Minor violation, first offense

SUSPENSION

50%

PENDING

Repeated violations, suspicious behavior

BAN

100%

BANNED

Malicious action, attack confirmed

All slashed YLD is burned. Economic pain is proportional to the severity of the violation.

2.5 Composable Interface

Any protocol integrates the registry with three lines of Solidity:

import "./interfaces/IAgentRegistry.sol";

IAgentRegistry registry = IAgentRegistry(REGISTRY_ADDRESS);
require(registry.isEligible(agent), "Agent not eligible");

The interface exposes three functions that cover all integration needs: isEligible(address) returns bool, score(address) returns uint256, and statusOf(address) returns the full lifecycle state. Protocols can set their own minimum score thresholds above the default 500.


3. Economic Model: Aligned Incentives

The design principle is that economic incentives should align agent behavior with protocol health without requiring active governance for routine cases.

3.1 YLD Token Utility

$YLD is the native token of the Yelden Protocol. In the registry, YLD serves two roles: it is the stake token that creates economic accountability, and it is the burn target that creates deflationary pressure. These are not separate mechanisms — they are the same mechanism.

When an agent performs well, they hold YLD and pay minimal fees. When an agent underperforms, their YLD is burned. When an agent is malicious, all their YLD is burned. The aggregate effect is that protocol quality and YLD supply are inversely correlated: more misbehavior means more burns means less supply.

3.2 Solving the Valorization Paradox

A naive staking design faces a paradox: if the staking token appreciates significantly, the cost of entry becomes prohibitive, and the registry closes to new participants precisely when it is most successful.

The subscription stake model resolves this. Governance can reduce the monthly fee denominated in YLD as the token appreciates, maintaining stable dollar-equivalent costs while the token price rises. The minimum stake of 50 YLD is adjusted by governance over longer time horizons. Score, critically, is never influenced by stake size — there is no incentive to over-stake to purchase a higher starting reputation.

3.3 Fee as a Signal

The fee structure encodes a continuous signal about agent quality. A protocol querying the registry can infer not just current eligibility but historical performance trajectory. An agent paying zero fees has demonstrated sustained excellence. An agent with a declining score is approaching self-elimination.

This is richer information than a binary whitelist. Protocols can implement dynamic trust levels based on score thresholds rather than a simple in/out gate.


4. Security: Pre-Audit Foundation

The registry was built on top of a vault core that completed a comprehensive pre-audit tooling stack. This is uncommon at seed stage and reflects a deliberate decision to establish a security baseline before building upward.

Tool

Result

Significance

solidity-coverage

95.88% lines

YeldenVault.sol: 100% line coverage

Mutation testing

10/10 killed

Every semantic change caught by test suite

Slither

40 findings

All low-risk — naming and immutable suggestions

Echidna fuzzing

3/3 invariants

10,000 call sequences, zero violations

Certora Prover

7/7 rules

Formal mathematical proof — no errors found

ZKVerifier Groth16

532 constraints

Real circuit — compiled, trusted setup, 16 tests passing

One real bug was found during this process. Echidna falsified the echidna_reserve_bounded invariant — the yieldReserve accounting variable can exceed totalAssets() after harvest() if no corresponding USDC deposit has been made. This was confirmed as expected behavior by design: harvest() is purely an accounting function. The invariant was updated in both Echidna and Certora specifications, and the design decision was documented.

Finding and documenting this correctly is the intended outcome of pre-audit tooling. The bug was caught before any deployment. The invariant update reflects the actual system invariants, not the ones we wished were true.

4.1 Access Control

The registry uses OpenZeppelin's AccessControl with three distinct roles. DEFAULT_ADMIN_ROLE is held by the protocol owner, targeted for multisig in production. SLASHER_ROLE is held by the Chainlink DON or DAO governance, and is the only address that can execute slash operations. SCORER_ROLE is held by the Chainlink DON and is the only address that can approve agents and update scores.

This separation ensures that score updates cannot be conflated with slash execution, and that administrative functions cannot be abused to manipulate agent reputations.

4.2 Reentrancy Protection

All state-changing functions that interact with external contracts use OpenZeppelin's ReentrancyGuard. The check-effects-interaction pattern is enforced throughout — state is updated before any token transfers are executed.


5. Open Questions for the Community

This paper is intended to open a conversation, not close one. The following questions are genuinely unresolved and the answers would materially affect the design. If you have worked on agent systems, keeper networks, or oracle design, these are the questions worth engaging with.

On Score Mechanics

  • What on-chain data should constitute objective score inputs? Uptime, task completion rate, slippage management, and liquidation efficiency are candidates — but the weighting is not obvious and gaming resistance is non-trivial.

  • Should score decay over time without updates? An agent that was excellent two years ago may be running on deprecated infrastructure today. Decay introduces complexity but may be necessary for long-term accuracy.

  • How should score handle the cold start problem for new agents with no history? The current answer — start at 300 — is a reasonable default but not necessarily optimal. An alternative is a bonding curve for initial score based on stake size, which reintroduces capital influence in a bounded way.

On Governance

  • Who should hold SLASHER_ROLE in production? A DON can automate slashing for objective metric violations. Governance is needed for subjective or novel attack patterns. The right answer is probably both with different thresholds — but the boundary between them is unclear.

  • How should the minimum stake and monthly fee adjust as YLD appreciates? Fully automated adjustment based on an oracle-reported price is possible but adds oracle dependency to the entry mechanism itself.

On Composability

  • Should isEligible() be the canonical interface, or should protocols access score() directly and set their own thresholds? The current design supports both. A standard that exposes only isEligible() is simpler; one that exposes score() is more powerful but harder to standardize.

  • Is there a case for an EIP standardizing the agent registry interface, similar to how ERC-4626 standardized vault interfaces? We are actively watching the ERC-8004 discussion on Ethereum Magicians and believe the economic accountability layer is missing from current proposals.


6. Roadmap

Phase

Component

Status

Phase 1

ERC-4626 vault + formal verification (Certora, Echidna)

Complete

Phase 2

AIAgentRegistry v3 — subscription stake, YLD burn, slashing

Complete

Phase 3

Groth16 ZKVerifier — 532 constraints, 16 tests, trusted setup

Complete

Phase 3

$YLD token — governance + staking collateral

Next

Phase 3

RWA adapters — Ondo, Centrifuge, Maple

Planned

Phase 4

Standard interface proposal — EIP for agent registries

Research

Total: 198 tests passing. 0 failing.


7. Conclusion

The question of how DeFi protocols should trust autonomous AI agents is not going away. The agents are already here. What is missing is the infrastructure to make their participation verifiable and accountable.

AIAgentRegistry proposes one answer: a composable on-chain primitive where trust is earned through verifiable performance history, maintained through continuous economic commitment, and lost through economic punishment for bad behavior. Score reflects behavior, not capital. Fees penalize underperformance automatically. Slashing punishes malice definitively.

The design is intentionally minimal. Any protocol can query isEligible(agent) and benefit from the shared reputation layer without building their own. The aggregate effect — if the registry achieves adoption — is a DeFi ecosystem where autonomous agents have something to lose, which is the only foundation on which accountability can be built.


Looking for a Technical Co-Founder

The protocol is built. The hard parts are done. What comes next requires someone who has gone deep on at least two of: Groth16 circuits and snarkjs, Chainlink DON architecture, ERC-4626 and vault security patterns, or formal verification tooling.

This is not a "we need someone to finish the work" situation. The core is complete and formally verified. What we need is someone to own the next layer — real ZK score circuits, Chainlink DON integration for the SCORER_ROLE, $YLD token design, and the audit process.

What we offer: 20–30% equity, 4-year vest, 12-month cliff. Technical co-founder title. Retroactive credit for prior contributions negotiable. Full architectural ownership of the ZK and oracle layers.

If you are reading this and you have an opinion on the open questions in Section 5, that is probably a signal worth following.

github.com/plongen/yelden-protocol
yelden@gmail.com
MIT License · February 2026