What Is Wallet Attestation
in the UCP Spec?

The Universal Commerce Protocol release of 25 August 2026 uses the phrase “wallet attestation” in its normative text. It never defines it. If you went looking for what it means and found nothing, this is that page — what the reserved slot is, how it got into the spec, and what would go in it.

What the spec actually says

Two places, both in the identity linking capability. The first is the schema, on the provider definition in identity_linking.json:

A trusted identity provider for delegated authentication, keyed by the
'type' discriminator. 'oauth2' denotes an OAuth 2.0 / OIDC authorization
server. Future versions MAY define additional types (e.g. wallet
attestation) as non-breaking extensions; platforms MUST treat entries
whose 'type' they do not support as filtered out (see Provider Selection).

The second is the Future Extensibility section of the identity linking specification, which describes provider.type as “a required, open string” where oauth2 is the only type defined in this version, and which “reserves space for future types — wallet attestation, verifiable credentials, or other proof-of-identity protocols.”

Read that precisely, because the precision is the interesting part. The slot is reserved, not filled. No platform is obliged to support wallet attestation, and verifiable credentials are named in the same sentence. What the spec does commit to is the mechanics of extension: type is an open string rather than a closed enum, so an unrecognised value validates instead of failing, and a platform that does not understand a provider entry must filter it out rather than reject the whole profile.

What wallet attestation is

It is a way to answer a question about a buyer without learning who they are. A verifier reads public blockchain state at a specific block, evaluates a condition the business defined, and returns a signed boolean. Not a balance, not an address, not a profile — a yes or no, with a signature over the condition that was evaluated.

The reason it fits beside OAuth rather than against it is that the four operations an identity system has to perform are already native to chain state:

• Issuance is a chain mutation. Someone minted, was granted, or bought the asset.
• Consent splits in two, and the distinction is worth being exact about. The durable half — I chose to hold this, and still do — is the on-chain act itself. The per-transaction half — I am choosing to show you, now — is the presentation: connecting a wallet, showing a code, tapping a tag. Possession on its own is not consent to disclose, so it is the presentation that carries that, never the holding. OAuth collapses both into one consent screen; here they are separate, and only the second is per-transaction.
• Revocation is a chain mutation too. Burn it, transfer it, drop below the threshold, and the next evaluation returns false on its own.
• Verification is a read of current state, signed, checkable offline against a published key set.

OAuth builds consent screens, token expiry, revocation lists and introspection endpoints to approximate those four things for account systems, and it does that well. The point is not that one replaces the other. It is that when the fact you need is already on a public ledger, you can read it directly, and the business never has to hold a session, host a consent page, or store anything about the person.

When you would reach for it

The shape is useful whenever a business needs to act on a fact about a buyer that it should not have to store, and that the buyer should not have to prove by logging in.

Member pricing an agent can act on. A shopping agent is completing a checkout on someone’s behalf. The business offers a better price to holders of a particular pass. Without something like this, the agent has to drive an account login it does not have, or the business has to trust an unverifiable assertion from the agent. With it, the business asks one question and gets a signed answer it can keep as evidence of why it applied the price.

Eligibility that currently requires an account. Student, alumni, union, employee, early-supporter, season-ticket — these are all facts that exist somewhere, and the usual way to check them is to make the person create yet another account, or to trust a photograph of a card. Where the underlying credential already lives on a chain, checking it is a read rather than an onboarding flow.

Shareholder perks an agent could actually use. Issuers have offered benefits to their own shareholders for decades — onboard credit, product discounts, meeting access — and the way you claim one is still to email a brokerage statement to somebody and wait. Tokenised equity does not change what is on offer; it changes what is checkable, because a holding becomes a ledger entry a business can evaluate the same way it evaluates any other wallet condition. The moment that stops being hypothetical is an agent completing a purchase on behalf of someone who holds the issuer’s stock, and wanting the holder’s price. The issuing side of that is being built now, by exchanges and registrars. Reading a holding at a checkout is a different question, and it is the one this mechanism answers — which is what we wrote about when an exchange pitched issuers on shareholder rewards and the register had no way to see the share.

Recognition across businesses that share nothing. A community issues one pass. Twenty independent shops honour it. None of them holds a customer list, none of them integrates with the others, and the community can add or remove members without telling any of them. Each business evaluates the same public fact independently.

Revocation that is actually current. A lapsed membership is the awkward case for token-based access, because a token issued last year says nothing about today. Here the check reads present state at a block: if the asset moved, was burned, or fell below the threshold, the next evaluation returns false with no revocation list to publish and no stale-token window to reason about.

And the boundary, because it matters as much as the cases: if the fact you need is not on a chain, this is the wrong instrument. It answers questions about wallet state. It does not tell you someone’s name, that they are over eighteen, or that they are who they claim to be, and no amount of signing makes it do so. For those, the spec reserved room for other mechanisms in the same sentence, which is the right outcome.

Compared with the alternatives

It is not better than the other mechanisms. It is better at one specific question — does this buyer’s wallet satisfy this condition right now — and worse at most others. The useful comparison is what each one costs you.

Against an account login. OAuth is the right answer when the fact lives in your database or an identity provider’s, and it is far better than this at anything involving a person’s profile. Agents can use it perfectly well, too — that is exactly what UCP’s identity linking capability is for, and the August release describes agents negotiating identity providers on a buyer’s behalf. What OAuth needs is that a human consented at some point. The consent screen is a human moment by design, and everything afterwards runs on the strength of it, which is a feature rather than a defect. It does mean the first encounter between a buyer and a business contains a person-shaped step. A wallet condition has no prior relationship to establish: the buyer already holds the thing, and the business reads whether they still do.

Against verifiable credentials. These are stronger wherever an authority has to vouch for something about a person — age, qualification, residency. The cost is an ecosystem: an issuer willing to issue, holder software, a status mechanism for revocation. When the fact is already a public ledger entry, that machinery is doing work the chain has already done.

Against calling a partner’s API. A lookup is fine when the partner owns the data. It leaves you with a live dependency, a bilateral integration per partner, and a partner who learns every question you ask. Chain state is readable by everyone independently, so twenty businesses can check the same fact without any of them integrating with each other or with the issuer.

Against a card, a code, or a screenshot. No contest, and this is the honest baseline for most in-person eligibility today. Those are trivially forged and leave no evidence afterwards. A signed result is checkable later by someone who trusts neither party.

Where it loses is worth being just as plain about. The fact has to be on a chain. It establishes nothing about identity, age or personhood. It requires the buyer to hold and present a wallet, which is a real adoption cost. And it is not privacy for the underlying fact — the ledger is public — it is privacy in what the business ends up holding, which is a boolean and a signature rather than an address or a balance.

How it got into the spec

Through review, which is how vocabulary usually enters a specification.

On 15 March 2026 we proposed the mechanism and its literal shape in the discussion thread on UCP issue #265 — a provider type of wallet_attestation carrying a provider_jwks URL, contributing no scopes and issuing no token. On 18 March a UCP maintainer quoted that block back into the thread. Both comments are public.

What happened next was not ours. In PR #354, which merged on 6 May 2026, the identity linking foundation established config.providers with a type discriminator and reserved room for non-OAuth mechanisms. In PR #423, merged 12 June, the maintainer made that extension structural rather than merely documented: type became an open string, each mechanism got its own conditional requirements, and unrecognised types were defined as filtered rather than rejected. We had argued for a different structure in that review and were overruled, correctly — the shape that shipped extends more cleanly than the one we proposed.

The release of 25 August carried that reservation into published normative text. Our own proposal for the concrete mechanism, PR #415, is open and unmerged. It is a proposal, not a standard, and this page is not claiming otherwise.

What a provider entry looks like

Inside the identity linking capability config, providers are keyed by reverse-domain name:

"config": {
  "providers": {
    "com.example.walletauth": [
      {
        "type": "wallet_attestation",
        "provider_jwks": "https://api.example.com/.well-known/jwks.json"
      }
    ]
  }
}

Because type is an open string and the provider object permits additional properties, an entry like this validates against the released schema as published. A platform that supports the mechanism resolves the key set and verifies attestations against it. A platform that does not filters the entry out and carries on with whatever else is advertised. Neither one breaks, which is what the forward-compatibility rule is for.

The verification itself is ordinary: fetch the key set, verify the ES256 signature, and check the hash of the condition that was evaluated so you know which question was answered. No callback to the issuer, no shared secret, nothing that expires in a drawer.

What this is not

It is worth being blunt about the limits, because they are checkable and you would find them anyway.

• UCP has not adopted wallet attestation. It reserved a slot and named it as one candidate.
• Verifiable credentials are named alongside it in the same sentence. Nothing privileges one over the other.
• oauth2 remains the only provider type defined in the current version.
• Our proposal for the concrete mechanism is open, not merged.

What is durable is smaller and more useful than an adoption claim: the extension point exists in released normative text, it names the mechanism, the mechanics of adding a type are specified, and a conforming entry can be written today. If you are building on UCP identity linking and want the wallet-state question answered without taking custody of an identity, that is the shape it takes.

Whether this becomes how agentic commerce checks eligibility, or one option among several, is not something this page can tell you — the slot is reserved and nothing is settled. For the wider argument about why checks that work without a human present are being asked for at all, that is a separate and more opinionated piece: From Passwords to Proofs.