Ledger Agent Stack · Key Ring · device confirmation

The tap between autonomy and the budget

The agents run autonomously up to the last irreversible step. Before a USDC budget is released, the enrolled Ledger signs the exact release parameters — pathway, budget, chain, quantum leg — after they are shown on its screen. The signature is recovered on the server against the enrolled signer and hashed into the sealed receipt. No tap, no settlement.

Bridge status

The app runs in an edge runtime with no USB, so the device is driven by a local bridge on your machine and the browser reaches it over loopback. The bridge holds no keys and keeps no state; every request needs the device present.

bridgeoffline — start scripts/ledger

device—

signer—

enrolled on this deploymentno — gate open

approval contextClinical Quantum Exchange — device approval

To make the gate mandatory, enrol the signer: read the address above and save it as the LEDGER_SIGNER_ADDRESS secret in Project Settings → Secrets. From then on, a run without the device's signature settles 0.00 USDC and says so. A Speculos session is enrolled separately with LEDGER_SIGNER_ADDRESS_EMULATOR and never touches the real device's enrolment.

Key Ring — secrets the agent cannot leak

The exchange's private credentials — the Circle entity secret, the Nexus token — do not sit in a hosted vault for the agent to read. They are sealed under keys derived from the Ledger seed with the Ledger Key Ring: one device tap to provision, then decryption needs no device at all. The agent requests a scoped, short-lived capability per pathway run; it never handles the underlying key.

Key Ring provisioning always uses the real Ledger Key Ring (trust chain) protocol on a physical device — Speculos never substitutes for it. One tap to provision; decryption afterwards needs no device at all.

provision (once, device present)wallet-cli ring init

seal a secret under a named keywallet-cli ring encrypt -i secrets.txt -o secrets.enc --key cqx

open it — no device, no vaultwallet-cli ring decrypt -i secrets.enc -o - --key cqx

list this machine's keyswallet-cli ring keys

The ring password comes from your OS keychain at call time — WALLET_PASS is injected, never typed. The bridge refuses to run ring commands with a literal password on the command line.

Before and after

before Ledger

Authority was software all the way down: a World proof said which human authorised the release, but the release parameters themselves — how much, to whom, on which chain — were assembled in code. The Circle entity secret and the Nexus token lived in a secret store any deployment could read.

after Ledger

The device sits between the agent's decision and the money. The release parameters are shown on a screen the agent does not control, signed by a key that never leaves secure hardware, and the approval is hashed into the receipt digest that is sealed with SLH-DSA and anchored on Arc. Secrets are sealed under the seed, so a leaked repo yields no keys.

Try it: open the pathway board, approve a release on the device, then run the job — the run ledger shows the device step between human authority and the classical floor.

How the check works

1. The browser builds the canonical release payload and sends it to the bridge over loopback.
2. The bridge shows the address on the device, then asks the Ethereum app to personal-sign the payload — you review it on the device screen.
3. The server rebuilds the same payload from committed data, recovers the signer with ECDSA verification, compares it to the enrolled address, and rejects anything expired or re-pointed at another pathway.
4. The approval travels into the receipt payload, so the SHA-256 digest that is SLH-DSA-sealed and anchored on Arc commits to the tap as well.