Mandate, not a hot key
The Agent receives permission to request specific operations under explicit limits. It never receives the Wallet private key.
Architecture discussion · draft 0.1
Shared control for autonomous money.
Ring29 Wallet gives an Agent useful, inspectable authority without handing it an unrestricted private key. Bring Your Own Signer Node is part of the core product.
The first outcome
One narrow path we can prove.
An authenticated Agent requests an x402 payment from a Wallet in a Vault. Control produces a bounded decision. A customer-managed or Ring29-managed Signer Node independently checks the request and signs only the fixed authorization type.
Signer decides locally
A Control signature is required, but it cannot override the Signer Node’s local Vault policy floor or quarantine state.
States stay separate
Approved, signed, broadcast, accepted, and settled are different claims with different receipts.
Product model
Seven nouns, one security boundary.
Customer language stays small. “Tenant” may exist inside infrastructure, but the customer creates and reasons about a Vault.
Organizationcustomer boundary
Vaultsigning domain
Walletchain address
Agentworkload identity
Mandatebounded authority
Guardianhuman approval
Signer Nodekey boundary
Important distinction: Guardian approval does not automatically add an MPC share. Approval policy and signing threshold are separate controls and must be represented separately.
Proposed signing flow
Verify meaning before producing a signature.
The Signer Node treats Control and transport as untrusted inputs. It reconstructs the exact signable operation from typed fields instead of accepting an opaque digest.
- Authenticate
Control authenticates the Agent through OIDC or workload identity and resolves its Organization, Vault, Wallet, and Mandate.
- Decide
Control evaluates the versioned Mandate. It records whether the request is allowed, denied, or requires Guardian evidence.
- Package
Control signs a short-lived package binding the Intent, decision, target node, Wallet, network, purpose, and nonce.
- Deliver
A Vault-scoped NATS identity delivers the command. Durable delivery is at least once, so idempotency is enforced at the node.
- Reconstruct
The node verifies the package, applies its local policy floor, checks replay and quarantine state, then reconstructs the fixed EIP-712 authorization.
- Sign
The configured ceremony engine runs: Solo first; Split or Quorum only after a selected MPC implementation passes its own review and tests.
- Report
The node durably records and signs its result. A later service may broadcast it; settlement evidence comes from the chain, not the signer.
Trust boundary
Control orchestrates. The node authorizes signing.
Ring29 Control owns
- Agent and Guardian authentication
- Vault, Wallet, and Mandate registry
- Policy decision and approval collection
- Command packaging and operation history
- Broadcast and settlement tracking when enabled
Signer Node owns
- Wallet key reference or MPC participant state
- Local Vault policy floor and emergency stop
- Independent package and chain validation
- Replay journal, result outbox, and quarantine
- The final decision to participate in signing
Decision ledger
What we keep, change, defer, or reject.
This is a clean-room requirements ledger. It records general security lessons and Ring29 decisions; it does not reproduce legacy source, APIs, message subjects, or recovery formats.
| Decision | Ring29 direction | Status |
|---|---|---|
| Independent node verification | Every signer reconstructs the supported operation and rechecks policy-relevant fields before signing. | Accepted |
| Typed Intent boundary | No generic eth_sign, arbitrary calldata, or opaque digest in v0. | Accepted |
| Approval and signing are separate | Guardian policy does not silently change the MPC threshold or participant set. | Accepted |
| Vault replaces customer-facing tenant | One Organization may own many small, independently quarantinable and migratable Vaults. | Accepted |
| Durable NATS commands | JetStream command and result streams with explicit acknowledgement, local idempotency, and a durable outbox. | Proposed |
| Two policy layers | Control evaluates the Mandate; the Signer Node enforces a local floor that Control cannot widen. | Proposed |
| Workload and node auth are distinct | OIDC authenticates humans and Agents to Control. NATS NKeys/JWT credentials identify node runtimes and scope subjects. | Proposed |
| Monotonic epoch and replay state | Persist package digests, policy version, membership epoch, and quarantine locally; reject stale or conflicting identifiers. | Proposed |
| Variable MPC topology | Expose Solo, Split, Quorum, and Unanimous only after protocol, liveness, resharing, and presignature behavior are selected and tested. | Deferred |
| Same-address resharing | Define atomic membership epoch changes, exclusion of suspect participants, rollback rules, and destruction evidence after choosing the MPC stack. | Deferred |
| Ledger Guardian recovery | Specify a custom Ledger app and redundant recovery ceremony without inheriting an RSA recovery format. | Deferred |
| All-participant threshold as the only mode | Ring29’s model requires an explicit, reviewable m-of-n topology; cryptographic library support alone is not product support. | Rejected |
| Remote quarantine clearing | Control may freeze a node, but cannot unfreeze a locally quarantined node without an operator or future Guardian procedure. | Rejected |
| Code-by-code legacy clone | Ring29 uses independently written interfaces and tests. Only public, compatibly licensed dependencies may be reused. | Rejected |
Vault signing topology
Threshold is not approval policy.
The Vault topology describes which Signer Nodes must cooperate. The Mandate separately describes when an Agent may request signing and whether a Guardian must approve.
1-of-1 Solo
Low latency
One signer. Useful for tightly funded bot Wallets. It is not meaningfully MPC.
2-of-2 Split
Shared control
Ring29 and customer cooperate. Either participant can stop activity.
2-of-3 Quorum
Availability
Any two sign. Human participation is not guaranteed unless policy requires it separately.
3-of-3 Unanimous
Ceremonial
Every participant signs. Strong coordination, lower availability, unsuitable for the fastest bot path.
Node lifecycle
A running process is not a ready signer.
| State | New signing | Meaning |
|---|---|---|
| enrolling | Deny | Identity and Vault binding are incomplete. |
| ready | Eligible | Policy, journal, clock, key backend, and NATS checks pass. |
| degraded | Deny | Dependency or integrity check failed; finish only an explicitly safe in-flight step. |
| draining | Deny | Stop taking commands, complete acknowledged safe work, then disconnect. |
| quarantined | Deny | Operator or remote freeze is active; Control alone cannot clear it. |
| offline | None | No processing until reconnect and full configuration revalidation. |
First review round
Decisions we should debate next.
These questions materially change the v0 implementation. Everything else can remain deferred.
Is the first hosted topology Ring29-managed Solo, customer-managed Solo, or both?
Both keeps the product promise honest, but customer-managed Solo makes enrollment, NATS authorization, upgrades, and support part of the first milestone. We should decide whether the first demonstrator proves both deployment modes or only preserves the interface for both.
Should each Signer Node process serve exactly one Vault in v0?
One process per Vault is operationally simple and creates a strong blast-radius boundary. Multi-Vault processes reduce cost but require careful storage, credential, resource, and failure isolation. Small Vaults suggest starting one-to-one.
Who owns the NATS account and credentials?
Hosted Vaults can use a Ring29-operated NATS account. Self-hosted Vaults can connect to customer NATS. The enrollment contract should issue identical subject-scoped permissions in either mode, with no password-only default for production.
Does Control broadcast the x402 authorization or return it to the Agent?
Returning a signature keeps signing and settlement loosely coupled. Broadcasting through Control gives a simpler receipt trail. The API can support both later, but v0 should prove one path and label each evidence state precisely.
What is the first local policy administration path?
A file-based policy with atomic reload is simple and operator-owned. A local admin socket is more dynamic but increases attack surface. Remote Control must never be able to widen this policy or clear quarantine by itself.
What exactly triggers quarantine?
Manual operator action is sufficient for v0. Later triggers may include conflicting package IDs, unexpected node identity use, attestation drift, protocol cheating, or impossible message sequences. Automatic quarantine should fail closed and require a documented recovery path.
Review boundary
Open repository
This draft is local and unpublished. Human review is required before a Here.now publication or any Git commit.