DFNS-vault-inspired agent-account receipt

From wallet balance to agent account receipt.

DFNS Vaults frame a useful shift from raw wallet balance to account-style state: available, quarantined, locked, incoming, outgoing, and auditable ledger entries. This Gregers proof borrows the accounting metaphor for AI-agent access: identity, authority, policy, cap, settlement, and receipt before a service says yes.

Core analogy
Wallets tell you what can pay. Agent accounts tell you what may be accepted.

A raw agent wallet can show funds. An accountable agent account should show what is available, what is held for verification, what capability is reserved, which policy applies, and what receipt survives. Practical claim: a seller/API can require verified agent identity, policy-bound spend cap, matching x402 settlement, and replayable receipt before releasing the resource.

Status
Reference proof

No DFNS integration, no custody claim, no partnership claim. This is a Gregers reference proof built on Concordium Agent Registry context and public DFNS framing. Not an official Concordium or Concordium Foundation communication.

Vault states → agent-account states

DFNS Vault conceptGregers agent-account equivalent
AvailableBalanceavailable authority / currently spendable permission
QuarantinedBalanceunverified agent request held before service or payment terms
LockedBalancetask-specific capability or spend cap reserved under policy
Incoming / Outgoingrequest and payment lifecycle before and after settlement
Append-only ledgerreplayable agent action receipt
Hold-then-release policyregistry, authority, policy and receipt acceptance check
Sealed-wallet control planeseller/API service gate that refuses unmatched requests

Receipt flow

1. Quarantine

Agent request starts held, not automatically accepted.

2. Challenge

Seller/API agent asks identity, wallet-control, policy, cap and receipt-binding questions.

3. Lock

Capability and spend cap are reserved to one resource and one policy.

4. Match

x402 settlement is matched to the accepted request.

5. Serve

Resource is served only after acceptance proof and settlement evidence match.

6. Ledger

Challenge hash, answer hash, policy hash, settlement tx and service verdict become the receipt.

Machine-readable receipt

schema: gregers.agent-vault-receipt.v1 receipt_hash_sha256: 7be8b778d2be576f7f927cc86a5a3e4b045debf45958dd2bc80b853846b6eb17 json: /api/gregers-agent-vault-receipt

Boundary

  • Reference proof only; no DFNS, Bankr, Coinbase, Base, x402, MetaMask, Concordium, or Concordium Foundation partnership/integration/endorsement is claimed.
  • This is not a DFNS Vault and does not use DFNS infrastructure.
  • This is not custody, treasury, financial advice, compliance advice, or regulated account infrastructure.
  • Receipts prove a signed record/hash was bound to stated metadata; they do not prove underlying data truth, suitability, compliance, or correct interpretation.