Application Dossier
Overview
AI agents are increasingly taking actions across apps, APIs, and hosted runtimes — but no outside service can verify, in real time, that an agent-signed action came from a credential the operator currently authorizes. Authorization lives in vendor-specific systems. There's no shared substrate for rotation, revocation, or audit.
ENS already provides the naming, discovery, and registry primitives. What it doesn't yet have, on top of those primitives, is an ENS-keyed authority-policy lookup layer: a resolver-level surface that lets any service confirm a signed action came from a currently-authorized credential under an ENS name, and that the credential hasn't been rotated, expired, or revoked.
The work detailed in this dossier fills that gap.
The counterfactual to SPP3 funding is not "no work happens." The framework and the spec are already public. The counterfactual is the work ships as single-runtime tooling by a single team, with no conformance surface and no public reference for other integrators, on a 24–36 month part-time arc — by which point vendor MAIPs (Microsoft Entra Agent ID, currently in preview) will have defined the cross-vendor verification pattern for the category, and operator-archetype MARPs that would otherwise adopt the open-MAIP pattern will have defaulted to vendor or platform-internal alternatives. The 12-month window matters because the category is locking in now.
Architecture and scope
A MAIPMAIP — Managed Agent Identity Platform. The identity substrate that MARPs, their agents, and counterparties resolve against. Open, vendor-neutral, indexable — in contrast to vendor-specific identity systems (Microsoft Entra Agent ID, AWS Bedrock Agents) that lock identity to a particular runtime operator. is the identity substrate that MARPsMARP — Managed Agent Runtime Platform. A hosted runtime where AI agents operate, with the platform handling the operational lifecycle — secret and credential management, scheduling, policy enforcement, durability, scaling, observability, and an identity surface. Both crypto-native (Pinata, Virtuals) and Web2-flavored (Anthropic Managed Agents) runtimes qualify. and their counterparties resolve against. Where MARP names the operator class running the agent, MAIP names the identity layer above the runtime.
A MAIP decomposes into three tiers — Display, Discovery, Authority — each answering a different question and decaying at a different rate. SPP3 funds Phase 1 / Authority tier only.
| Tier | Question it answers | Primitives | Maturity |
|---|---|---|---|
| Display | What is this agent? | Identity binding, naming, profile metadata (ENSIP-25, -26, -64) | mature |
| Discovery | Where do I reach it and what can it do? | Service endpoints, capability descriptors, wallet pointers | uniform shipped · selective is Phase 2 |
| Authority | Is this action currently authorized? | Real-time capability validity, revocation, signed-freshness state (Verifier + AuthResolver) | SPP3 scope |
The tiers also decay differently, which motivates their architectural separation:
- Display state is mostly stable. Aliases, avatars, and identity bindings change rarely. Indexers can cache aggressively.
- Discovery state changes per deployment. Endpoints rotate, capabilities extend, services come online and retire. Indexers need periodic refresh.
- Authority state is dynamic and adversarial. Revocations must propagate within seconds, not hours. Caching is hostile to correctness.
Phase roadmap (longer arc than SPP3)
| Phase | Scope | Window |
|---|---|---|
| Phase 1 | Authority tier — Verifier + AuthResolver, TypeScript SDK, conformance suite, three Wave-1 pilot integrations | SPP3 cycle (July 2026 – July 2027) |
| Phase 2 | Selective discovery — caller-bound CCIP-Read prototype across four use-case clusters (compliance, anti-abuse, monetization, tier differentiation) | Post-SPP3 (contingent on Phase 1 outcomes) |
| Phase 3 | MAIP consolidation — ENSIP standardization for Authority + selective Discovery, multi-MARP production adoption, possible NIST NCCoE cross-publication | Longer horizon |
This application funds the Phase 1 base ask, with an optional Phase 2 prototype budget gated on Phase 1 milestone progress (see Tiered request). Phase 3 is named here for context only — its work cannot start until Phase 1 and Phase 2 have shipped and accumulated in-the-wild evidence. The three-tier framing is what lets Authority ship independently with a defined scope and conformance surface — rather than being conflated with primitives at adjacent tiers (MCP/A2A wire-protocol auth, ERC-4337 session keys, UCAN/CACAO capability tokens, etc.).
Why MARPs are the wedge
The wedge is MARPs (Managed Agent Runtime Platforms) — Bankr Agents, Pinata Agents, Virtuals Protocol, ZeroDev/Kernel-backed runtimes. MARPs are where most agents will run in practice; integrating the AuthResolverAuthResolver. Per-name UUPS proxy on top of ENSv2's PermissionedResolver, holding credential / capability / revocation records. Deployed via VerifiableFactory. Read-side of the Authority tier — relying parties resolve it to learn what an ENS name is currently authorized to do. at a MARP's subname-issuance layer means every signup becomes a verifiable ENS-named agent at deployment time.
The committed floor is three Wave-1 per-agent pilots. The structural ceiling is MARP-layer integration.
| Dimension | Per-agent pilot | MARP-layer integration |
|---|---|---|
| Registration math | Linear with manual integration effort | Per-platform-user — every signup is a registration |
| Scale | ~10² registrations per pilot | 10⁴+ on initial integration, ramping to 10⁵+ within 12 months |
| Identity surface | Wallet + platform API key (no external naming) | Publicly resolvable named-agent identity that travels with the user |
| Authority model | Vendor-database trust | ENS state as independent reference — cryptographic integrity replaces vendor trust |
| Counterparty reach | Platform-specific integrations only | Reachable from 8+ existing ecosystems via one integration: other MARPs, MCP/A2A servers, ERC-4337 / ERC-6900 smart accounts, ERC-8004 registry consumers, UCAN/CACAO relying parties, ENS-aware wallets/dApps, EAS-style attestation networks, compliance tooling |
Why this matters for ENS DAO
- Subname issuance volume. Each MARP integration converts platform user signups into ENS subname registrations. A single operator-archetype MARP at production scale generates 10⁴+ subname registrations at integration go-live, ramping toward 10⁵+ over the subsequent 12 months — two to three orders of magnitude beyond the per-agent floor.
- Renewal incentive baked in. Any production agent whose ENS-bound credentials are in active use has direct operational incentive to renew the name, because revocation/rotation flow through the AuthResolver attached to that name. ENS names become operationally load-bearing for the agent, not decorative.
- First-mover dynamics. Once one MARP integrates, subsequent MARPs copy the pattern rather than design one. Compatibility with the first integrated MARP becomes a competitive feature.
- Architectural compatibility confirmed; end-to-end wiring is upcoming work. Bankr's POST
/wallet/signendpoint produces standard secp256k1 ECDSA signatures, but because Bankr wallets are EIP-7702-delegated smart accounts,ecrecoverreturns the underlying Privy EOA — not the wallet's onchain address. For agent-identity bindings rooted at the wallet address, EIP-1271isValidSignatureon the delegated implementation contract is the correct verification path. Both ECDSA-secp256k1 and EIP-1271 are in v1 VerifierVerifier. Stateless dispatch contract (one shared per chain) handling three signature schemes in v1: WebAuthn-ES256, ECDSA-secp256k1, EIP-1271. Called byverifyActionafter AuthResolver returns the name's current authority state. scope.
Bankr engagement is pre-commitment, not contracted. Neither the milestone structure nor the Wave-1 pilot floor depends on Bankr's adoption. Per-agent pilots are committed; MARP-layer integration is the structurally enabled outcome the toolkit is built to convert.
Proposal
Base ask: $350,000 over 12 months (July 2026 – July 2027). Optional expanded tier up to ~$475,000, gated on Phase 1 milestone progress — see Tiered request below. A toolkit delivered across four milestones. Full text in application.md; this dossier links to specific artifacts rather than duplicating them.
What we ship
- Two onchain contracts: a Verifier (one shared per chain; three signature schemes — WebAuthn-ES256, ECDSA-secp256k1, EIP-1271) and an AuthResolverImpl (per-name UUPS proxies via VerifiableFactory, holding credential / capability / revocation records).
- A TypeScript SDK that resolves ENS-published authorization state and verifies signed requests against current state.
- A conformance suite with reproducible test vectors for verifier behavior.
- Integration guides + three Wave-1 pilot integrations with hands-on engineering support.
- A third-party security audit of the Verifier and AuthResolver.
What this is NOT
A wallet, a consumer-onboarding flow, a generalized agent platform, schema-ization of ENSIP-26 records, or a competitor to capability-token systems. Focused infrastructure service. ENS Infrastructure objective category, with Outreach + Integrations secondary.
Tiered request
The ask is structured base vs. expanded. The base is the full, scoped Phase 1 deliverable set — committee can fund it with confidence that nothing inside the bundle is speculative. The expanded tier pulls the Phase 2 prototype forward into the cycle, with the additional budget released at month 9 contingent on Phase 1 M2 milestones being on-track(SDK + conformance suite shipped, pilots scheduled).
| Tier | Scope | Budget | Status |
|---|---|---|---|
| Base | Phase 1 — Verifier + AuthResolver, TypeScript SDK, conformance suite, three Wave-1 pilot integrations (Pinata / Virtuals / x402), third-party security audit, ENSIP draft. M1 – M4. | $350,000 | requested |
| Expanded | Base + Phase 2 prototype: selective-discovery (Path B — caller-bound CCIP-Read) architectural design and reference implementation, with empirical evaluation against one of the four use-case clusters (compliance / anti-abuse / monetization / tier differentiation). | ~$500,000 | contingent |
Live roadmap
Milestones
| Milestone | Status | Proof | Target |
|---|---|---|---|
| M0 — Application submitted | done | repo | 2026-05-23 |
| M0.5 — AuthResolver Phase A pilot | done | authtest.bankrtest.eth | 2026-05-21 |
| M1 — Verifier + AuthResolverImpl deployed to ENSv2 (testnet first; mainnet contingent on ENSv2 mainnet timing) | pending | — | 2026-10 |
| M2 — TypeScript SDK + conformance suite | pending | — | 2027-01 |
| M3 — Three Wave-1 pilot integrations (production-like) + third-party security audit | pending | — | 2027-04 |
| M4 — Integration pattern docs published; ENSIP draft submitted; v1.0-final spec | pending | — | 2027-07 |
KPIs
Operational success metrics (from the application) and trajectory KPIs (in-cycle + 12 months forward).
| Metric | Current | Target | Source |
|---|---|---|---|
| Revocation propagation latency | — | < 60s | app spec |
| Replay rejection rate | — | ≥ 99.9% | conformance suite |
| Policy-deny correctness | — | 100% | conformance suite |
| Developer onboarding time to working basic verification | — | < 1 day | SDK + docs |
| Wave-1 pilot integrations live (production-like) | 0 | 3 | M3 |
| Operator-archetype MARP integrated at subname-issuance layer | 0 | ≥ 1 | M4 + 12mo |
| ENS subnames issued via AuthResolver pattern (at M4) | 1 | 10⁴+ | integrated MARP(s) |
| ENS subnames issued (M4 + 12mo trajectory) | — | 10⁵+ | integrated MARP(s) |
| ENSIP draft submitted for authority-policy lookup layer | no | yes | M4 |
Evidence
Index
Catalog of artifacts the proposal references — code, transactions, posts, specs.
Spec + normative surface
- Prototype Spec: Verifier + AuthResolverImpl — v1.0-draft.02 (frozen). 55 normative conformance criteria across §3.6 (16), §4.8 (26), §5.4 (13).
- Spec Brief — Brief — Verifier + AuthResolverImpl
- Context / Work Brief — Service Provider Program — Context
Shipped artifacts
- ERC-8004 Identity Registry (Base mainnet) — 0x8004A169…a432
- Agent ID #19327 (Base) — registration tx
- NameStone CCIP-Read resolver (Base) —
0xA87361C4E58B619c390f469B9E6F27d759715125 - ENS x Bankr integration — BankrBot/skills PR #189 (feat/ens-agent-identity)
Timing-window proof (why now)
- EIP-7951 (P-256 precompile) shipped in Fusaka, 2025-12-03
- ENSIP-25 merged
- ERC-8004 reached mainnet, 2026-01
- Microsoft Entra Agent ID in preview (vendor MAIP for the same category)
Bankr compatibility — primitives mapped (wiring is upcoming work)
- POST
/wallet/sign→ standard secp256k1 ECDSA signatures.ecrecoverreturns the underlying Privy EOA, not the wallet's onchain address. - Bankr wallets are EIP-7702-delegated smart accounts. Verifying against the wallet address itself requires EIP-1271
isValidSignatureon the delegated implementation contract. - Both ECDSA-secp256k1 and EIP-1271 are in v1 Verifier scope. End-to-end integration is upcoming work — primitives are mapped, contract topology is described, wiring is not yet shipped.
Context: thesis publications
- ENS Forum — MARP thesis (operator-class framing)
- ENS's next growth wedge is here: Managed Agent Runtime Platforms
FAQ — committee objections
Anticipated objections with the relevant evidence inline.
How is this different from MCP/A2A, ERC-4337 session keys, or capability tokens (UCAN/CACAO)?
Those answer different questions. Wire-protocol auth answers "did the client present valid credentials at this connection?", not "are these the credentials the operator currently authorizes." ERC-4337 session keys execute scoped permissions onchain but don't tell a relying party which keys are currently the ENS name's authorized ones. Capability tokens prove a delegation existed at signing time, verified offline — they don't reflect current state. The gap is lookup: an ENS-keyed authority-policy surface relying parties can call. That's what this proposal delivers.
What if Bankr doesn't adopt at the MARP-layer?
Neither the milestone structure nor the Wave-1 pilot floor depends on Bankr's adoption. Bankr engagement is pre-commitment, not contracted. Per-agent pilots are committed; MARP-layer integration is the structurally enabled outcome the toolkit is built to convert.
Why ENS, why now?
ENS already has the surrounding primitives (ENSIP-25 / -26 / -64, ERC-8004), and ENSv2's substrate is ready today (per-name resolver instances, EnhancedAccessControl, IDataResolver, VerifiableFactory). The 12-month window matters because the category is locking in now — Microsoft Entra Agent ID is already in preview as a vendor pattern; once that lands, the cross-vendor verification pattern defaults to a vendor stack rather than an open ENS one.
What's the proof you can ship?
AuthResolver Phase A pilot was built and validated end-to-end on 2026-05-21 against authtest.bankrtest.eth (publish, resolve, verify, clobber-prevention). The spec is frozen at v1.0-draft.02 with 55 normative conformance criteria. Prior shipped work includes the ENS x Bankr integration (PR #189) and ERC-8004 agent registration #19327 on Base mainnet.
How are you managing the risk of "architectural beauty over proof"?
The spec is composition of 12 existing standards, not new core protocol. Phase A is already shipped against a live test name. Each milestone has a concrete deliverable, not a research target. Conformance tables (§3.6, §4.8, §5.4) gate "done" with binary criteria.
Why is this SPP funding rather than a grant?
The counterfactual (above) — without SPP-funded conformance + reference work, the toolkit ships as single-team single-runtime tooling on a 24–36 month part-time arc, by which time vendor MAIPs define the cross-vendor pattern. SPP3 buys the window to publish a public reference and ENSIP before that locks in.
Updates / changelog
- 2026-05-25 — Dossier site scaffolded at spp3.steg.eth.link.
- 2026-05-23 — Application repo steg-eth/spp3 published.
- 2026-05-21 — AuthResolver Phase A pilot built and validated end-to-end on
authtest.bankrtest.eth(clobber-prevention proof passed). - 2026-05-18 — Prototype Spec v1.0-draft.02 frozen and published.
- 2026-02-24 — ENS x Bankr Agent Identity integration submitted as BankrBot/skills PR #189.
- 2026-01-26 — ens-contracts PR #509 merged: EIP-7951 P-256 precompile wired into ENS canonical contracts, replacing the software
EllipticCurveimplementation for DNSSEC Algorithm 13. Authored by estmcmxci.eth. - 2026-01 — ERC-8004 reached mainnet.
- 2025-12-03 — EIP-7951 (P-256 precompile) shipped in Fusaka.