Native delegation: agents that sign for you without holding your keys.

There is a UX problem coming for every chain that wants to host autonomous agents, and most chains have already solved it the wrong way.

The problem. I want my agent to sign attestations on my behalf for the next 24 hours, scoped to one schema, with a clear way to limit blast radius if it goes rogue. The agent should not hold my master key. I should not have to sign every individual action. The chain should know the difference between me and the agent, and slash the right reputation when something breaks.

On Ethereum the answer is ERC-4337 plus a SafeWallet variant plus a paymaster contract plus a bundler. On Cosmos it is the x/authz module. Both work. Both are application-layer patterns running on top of a chain that does not natively know what delegation means. The chain just sees "a smart contract said yes."

Ligate Chain does not have general-purpose smart contracts. That is a design choice, not a constraint. So we made delegation a runtime primitive instead. This is the why and the rough how. The full paper is at v0.1 outline; v0.2 lands when Iris engineering does. Here, the argument.

What native delegation means, in two paragraphs

A user has a master key. They issue a MsgDelegate transaction signed by that key, granting a hot key the right to sign specific actions under specific schemas for a fixed window of blocks. The grant is one transaction, lives in chain state, and the runtime checks every delegated transaction at mempool admission against the grant: is the hot key authorized? Is the action in scope? Are we still inside the time window?

When the time window expires, the grant is gone. No revocation transaction needed. If the user wants to revoke early, they sign one more transaction (MsgRevokeDelegate) and the grant invalidates, optionally with a short grace period for in-flight agent actions. The lifecycle is a four-state machine (proposed, active, revoked, expired) with deterministic state transitions and no off-chain reconciliation.

That is the whole primitive. One transaction to grant, one to revoke, a fixed cost per delegated transaction (a few extra bytes plus one state lookup), and the protocol enforces scope and time-bounds without an EVM sitting on top of it. ERC-4337 overhead is typically 2x to 4x; ours is roughly 10%.

Why runtime, not contract

Three reasons, in increasing order of how much they matter.

Cost. Mempool-level rejection of unauthorized actions is cheaper than a contract-layer revert. If the hot key tries to sign something out of scope, the transaction never makes it into a block. No execution, no gas wasted validating the failure.

Light-client verification. A grant is a single state-tree lookup. On a contract-based system you traverse a contract's storage layout and trust that the contract is implemented correctly. Single lookup vs nested storage indirection.

This is the one that matters. PoUA reputation lives at the protocol layer. If you put delegation in a contract, you re-implement the §4.3 reputation update rule inside that contract, and now you have two sources of truth that need to agree. Slashing inheritance becomes "is the contract correctly forwarding the slash to the right key?" and the answer is "depends on the contract." Native delegation gets one slashing accountant, and it is the chain.

The slashing question we are still arguing about

When a hot key signs something that earns a slash, whose reputation drops? The user's? The agent's? Both?

Three rules, all defensible.

Master-only. Hot key is treated as an extension of the master. Agent slashing reduces the master's reputation per PoUA §4.3. Rationale: you chose to delegate, you bear the consequences. Risk: people stop using agents because the cost of one bad agent run could nuke their validator reputation.

Hot-only. The hot key has its own zero-initialised reputation; slashing applies only there. The master is unaffected. Rationale: agent misbehavior should not punish the user. Risk: nobody monitors agents, a market for malicious agents-for-hire shows up, your chain has a sybil-rental problem.

Both-slashed. Slash applies to both, at different severities. Rationale: master incentivized to monitor, hot key has skin in the game. Risk: more complex accounting, and small slashing events become large total reputation losses.

We are leaning both-slashed at a 1:0.3 ratio. Master loses full reputation share, hot key loses 30% as much. This gives the master a 70% safety buffer (small misconfigurations do not destroy them) while still creating a meaningful incentive to watch what their agents are doing. If anyone has a proof for a different ratio, the issue tracker accepts patches.

The candidate theorem for v0.2: under the assumption that adversaries maximize EV and reputational damage is per-key, the both-slashed rule is the unique inheritance rule that incentivizes both monitoring and disciplined behavior without double-punishing the master for routine agent variance. We have a sketch. We do not have the proof. This is exactly the kind of thing the reviewer cycle is for.

Iris is the product behind this paper

This paper exists because of Iris. Iris is Ligate's MCP server plus USD-billed relayer for autonomous AI agents. The agent runs MCP, the relayer pays gas in $LGT, the user pays Iris in dollars. The whole flow falls apart if "the user signed once, the agent acts for the next 24 hours" cannot be expressed at the chain layer.

The canonical Iris flow:

1. User opens Mneme wallet, signs MsgDelegate granting iris-agent.v1 schema scope to a per-session hot key, time-bound to 24 hours, both-slashed at (1, 0.3).
2. Hot key loads into the agent's runtime.
3. Agent submits attestations signed by the hot key. Iris pays gas. PoUA reputation accumulates on the master from good behavior, or on both from a slash.
4. At the end of the time window the grant expires automatically. No follow-up tx needed.

The user signed once. The agent acted for 24 hours. The chain enforced scope, time, and slashing without an ERC-4337 EntryPoint contract.

What is not in v0.2

A few things on purpose, because v1 does not need them.

Recursive delegation. Hot key further delegating to a sub-key. Useful, but it forks the design space (depth limit, scope monotonicity, cascade revocation) and we are saving that for v0.3 once the single-level mechanism has devnet validation.

Cross-chain delegation. Grant portability across IBC-connected chains. Out of scope. Separate paper.

Privacy. A user delegating to multiple hot keys reveals the delegation graph. Zero-knowledge variants are research-grade and not a v1 priority.

Quantum-resistant signatures. Out of scope. The delegation mechanism is signature-scheme-agnostic; whatever the master-key scheme is, delegation works the same way.

Where to argue with us

The paper at v0.1 is a scaffold. Section headings, intent annotations, the candidate slashing-inheritance theorem, the open questions. v0.2 fills it in when Iris engineering reaches the design-doc phase, which is also when external review starts to pay back the most.

If your area is mechanism design, agent-on-behalf-of-user UX, wallet security, or restaking-style operator delegation, we want the challenge. The issue tracker is here. Open one, push back, tell us why we are wrong about the both-slashed ratio or the recursive delegation deferral. We will argue back when we have time.

This is one of six papers in the research repo right now. PoUA is in external review. Three more (per-schema fees, native DA, this one) are scaffolds with paths to v0.2. Two (cross-schema composition, time-locked attestations) are explicitly deferred until specific design-partner asks land. We have opinions about which order they ship in. Most of the opinions are wrong. The repo is the place that gets rewritten as we find out which.