Cover photo

Managed Agent Runtime Platforms

The next operator class is here. ENS should be its identity layer.

Coinbase's cb.id rollout in September 2022 produced over 11 million subnames — roughly 5× total .eth at the time — by making ENS the default identity payload for Coinbase Wallet. An operator class, like Coinbase Wallet, is a category of platform that issues identity to users at scale. ENS has followed that same growth pattern since.

Wallets are one operator class. Another is now emerging in agentic commerce: Managed Agent Runtime Platforms (MARPs).

We believe this is ENS's next growth wedge.

What are Managed Agent Runtime Platforms?

Originally introduced on the ENS Forum — MARPs are hosted platforms that run production agents and handle the operational lifecycle on the operator's behalf (things like secrets management, scheduling, policy enforcement, durability, and scaling).

One example of a MARP is Bankr — a managed runtime that abstracts wallet operations, cross-chain transaction execution, security screening, gas sponsorship, and automated fee-to-compute funding so agents can operate in production without custom infra.

In other words, think of Bankr like an agentic wallet with a managed runtime.

Like Coinbase Wallet, Bankr operates accounts that perform economic transactions — its agents sign transactions, call contracts, and move funds across chains on behalf of the operator.

To counterparties today, each of those actions appears as a signature from an unnamed wallet, with no authorization context and no way to verify what the agent behind the key is allowed to do. Coinbase Wallet closed that same gap for users in 2022 by making cb.id the default identity payload at signup — one decision, 11 million names.

MARPs face the same gap one layer in: for agents instead of humans.

Addressing the Gap

Every MARP today ships its own policy lookup for its agents — there's no shared substrate underneath them yet to consult. A relying party calling the agent has no neutral place to ask, is this agent allowed to do what it just signed for?

They either trust the vendor or trust the signature blind.

What's lacking is a persistent identifier that outlives any single key, hosting runtime, or capability grant — and remains verifiable to every counterparty.

A neutral identity layer, like ENS, fixes that — for MARPs themselves as much as for the relying parties that depend on them.

However, the primitives necessary for an authority substrate, or an auth lookup layer, are not yet built out. With them, ENS can deliver an open, portable, cross-platform Managed Agent Identity Platform (MAIP) — giving MARPs a neutral identity layer that travels with their agents wherever they act onchain.

The substrate is the missing piece. The payload type — what those names carry — is the next thing ENS needs to add.

Authority-policy records are the next payload.

What changes when MARPs issue subnames

When a MARP's signup flow itself hands out <username>.<marp>.eth subnames with authority-policy records baked in, the shape of the product changes:

Dimension

Before (today's MARPs)

After (MARP-layer adoption)

Identity surface

Wallet address plus platform's own API key. No outside name, no outside authorization context.

Each user owns an ENS subname; their agents' signatures resolve back to it. Counterparties read the name directly — no platform API needed.

Counterparty reach

Reachable only via platform-specific glue. Outside parties treat platform-signed messages as black-box signatures.

One shape reaches everything already in the field: other MARPs, MCP and A2A servers, smart-account stacks, ERC-8004 registries, capability-token consumers, ENS-aware wallets, and audit tools.

Authority model

Platform is the sole source of truth for what an agent can do. Counterparties trust the platform or trust signatures blind.

ENS state is an outside reference. Counterparties check the public substrate. Ownership moves and revocations show up publicly at action-time.

Registration math

Per-agent — name counts grow with hand-rolled wiring.

Per-platform-user — every signup is a name. Two-to-three orders of magnitude past the per-agent floor.

Once the toolkit and SDK are built on top of the auth lookup layer, named-agent identity can be issued at the MARP's signup layer, not per agent. And once the model is proven by a single early-adopter MARP, it becomes a reusable template — one that compounds the ENS growth wedge.

What's mapped, what isn't

Bankr's POST /wallet/sign endpoint produces standard secp256k1 ECDSA signatures. Because Bankr wallets are EIP-7702-delegated smart accounts, the signer recovered via ecrecover is the underlying Privy EOA, not the wallet's onchain address.

To verify a signature against the wallet identity itself, a relying party must use the wallet's EIP-1271 isValidSignature — which is implemented on the delegated implementation contract. Both schemes are first-class in our planned Verifier (ECDSA-secp256k1 and EIP-1271); for agent-identity bindings rooted at the wallet address, EIP-1271 is the correct path.

The contract pattern isn't speculative either. We've already shipped a working version of the split — a DNSSEC-based TLD-claim system that fetches cryptographic proofs offchain, submits them onchain, and verifies them against onchain state through a two-contract pattern: an orchestrator holding claim and timelock state, plus a focused verifier consuming a precompile-backed primitive.

Swap the proof type from DNSSEC RRSIG to WebAuthn or ecrecover and that's the AuthResolver-plus-Verifier primitive necessary to build out an auth lookup layer on ENS. The architectural seam is already field-tested onchain.

The wiring itself is upcoming work — nothing is integrated end-to-end yet. The primitives a verifier needs are the same ones a MARP already writes down, and the contract topology to consume them is what we just described. The technical surface is mapped; the bar is platform-side buy-in, not whether the tech works.

The closed alternative is already shipping

Entra Agent ID is Microsoft's closed enterprise identity solution for agents. It's a MAIP for spinning up production agent IDs with parent-child structures, governance and compliance, policy controls, and provenance. It's available today to all Entra clients deploying production agents.

KPMG's Q1 2026 US AI Pulse, surveying $1B+ US firms, found 54% are already running AI agents.

The stakes are set: if ENS doesn't fill the authority-policy lookup gap, each MARP ships its own auth stack and ENS becomes a thin naming label over splintered trust — Web2 SSO redux for the agent economy.

The bet

Steg is building the open substrate underneath — the auth-lookup primitives that let any MARP issue ENS-native identity to its agents at signup, without owning the lookup layer itself. The bet is that the first MARP to integrate sets the pattern the rest follow; that ENS, not a closed vendor, becomes the identity layer for the agent economy.

If you're shipping a MARP and weighing your own identity stack — or a counterparty that needs to verify what an agent just signed for — we'd love to talk.


The position paper — including the proposed Authority primitive substrate and what it would take to deliver an open, portable MAIP on ENS — is at discuss.ens.domains/t/the-next-operator-class-managed-agent-runtime-platforms