A custody withdrawal, from the request to the chain, with people in the right place.
An illustrative walk-through of the control model AlphaPoint Cloud is designed around: an app and its policy running attested on Secure Core, a separate signing display where a person reads and holds to approve, and a co-signer that is designed to sign only what was approved. You will read one request and approve it yourself. The approval goes nowhere.
Request a 30-minute Security Briefing- End to end
- The problem
- Secure Core secures itself
- What your people see
- Your turn
- What happened next
- Checks on the code
- Close
End to end, in a custody workspace
In this design, your app, its policy and the workspace's API co-signer run attested on Secure Core. People decide on a separate signing display. The aim of the design: software in the middle cannot change the outcome.
The device's own tour frames this for a Fireblocks-style workspace. Here the name describes the kind of custody setup; it does not describe a built integration, an endorsement or a deployment.
Illustrative. The co-signer and its policy inside Secure Core are a design, not a built integration.
One breached laptop is enough.
A stolen API key requests the transfer, or a pushed code update approves it. An MPC signer signs what it is asked to sign.
This is the failure the walk-through is built around: the signing machinery is honest, and the thing that tells it what to do is not.
Secure Core secures itself.
In this design Secure Core rotates the API key. The only copy lives in its HSM: non-exportable, and usable only by your app under your policy.
- ✓Generated inside the HSM
- ✓Non-exportable: no other copy exists
- ✓Used only by your app, under your policy
- ✓Rotated by Secure Core. No person handles it
Design, not built: the key held non-exportable and rotated by Secure Core. On a platform without an HSM the key would be generated inside the enclave and sealed by an HSM-backed key.
What your people see.
When your policy or app wants human approval, a request on the Signing Display looks like this.
- 1What it isIts kind and its risk, up front.
- 2How muchThe amount, large.
- 3Where it goesThe full address, never a hash.
- 4Who vouchesThe custody platform, a screening service and Compliance, each signed.
- 5Your policyTwo holds, or no signature.
The screen drawn from the request's fields, the refusal of anything it cannot show, and the hold all run on the bench prototype. The device is a design, not a shipped unit.
✓ Custody platform · created, two signers
✓ Screening · low risk4
Your turn.
Read it, then decide. Both Approve and Decline are holds: press and keep holding for 1.5 seconds; a tap, or letting go early, does nothing. Approve arms only once you have scrolled to the end of the request.
Keyboard: Tab to Approve or Decline, then press and hold Space or Enter. The request, its hashes and its signed statements are made-up demo data from the device's own tour. Nothing is sent anywhere.
PASSTreasury · balance and daily limit cover it
- Customer
- ACC-00412, available 61.0 ETH
- Daily limit
- 200 ETH; 48.25 used after this
- Destination
- One-time address: the warning on the request is the system's
- Signed
- 2026-11-04 10:40 UTC · key in the trust store
INFOCustody platform · created; needs two signers
- Webhook
- TRANSACTION_CREATED, then PENDING_AUTHORIZATION
- Policy
- Rule 7: Treasury hot to external over 100,000 USD: 2 designated signers
- Fee
- Medium, 0.0009 ETH at creation
- Signature
- verified against the platform's published key (demo data)
PASSScreening · destination low risk
- Score
- 9 of 100 (low)
- Exposure
- None to sanctioned entities, mixers or darknet markets
- Run by
- the platform's screening integration at creation (demo data)
the hash you saw is the hash signed
- BOUND TO
- this request
- APPROVALS
- 2 of 2 · quorum met1 of 2 · declined · quorum not met
- YOUR KEY
- this device · P-256
- RECORDED
- approval · in the audit logdecline · in the audit log
Four steps. No shortcuts.One hold short. Nothing moved.The trace follows your decision.
Your policy decides how many people a transfer needs: none for the routine, two for this one. Only then does the co-signer sign.
Your policy needs two people for this transfer. One declined, so the quorum is not met and the co-signer has nothing to sign.
Your policy decides how many people a transfer needs: none for the routine, two for this one. No decision has been made in this walk-through yet.
- Your approval is cryptographically signed and sent to Secure Core.
- Secure Core counts it: two of two people have now approved.
- The co-signer asks your policy: may I sign this?
- The policy checks the transfer against what you read. Every detail matches.
- The policy says yes.
- The co-signer signs. Its key never leaves Secure Core.
- The custody platform sends the transfer. It is confirmed on chain.
- Your decline is cryptographically signed and sent to Secure Core.
- Secure Core counts it: one of two approved, one declined. The quorum is not met.
- The co-signer is never asked to sign. Its key does not move.
- The request is closed as declined and recorded in the audit log.
- In this design the pending transaction is cancelled. Nothing leaves the vault.
Go to step 5, read the request and hold Approve or Decline; this step then shows what follows from your choice. Nothing in it is signed or sent either way.
In this run you approved (a simulation).In this run you declined (a simulation).No decision yet. Illustrative; nothing was signed or sent.
Built: the display's approval signature and the one rule behind it (no signature without a hold over the hash that was shown), which is proved with a model checker. Design: the co-signer and its policy running inside Secure Core, and the key share released only to that approved code.
- Secure CorePolicy checkYour policy decides who must approve.
- Signing DisplayPeople approveNone for routine transfers. Two for this one: both held.Two needed for this one: one approved, one declined. Quorum not met.None for routine transfers. Two for this one.
- Secure CoreCo-signer signsOnly what was approved. The key never leaves.Does not happen: the co-signer is never asked.Only what was approved. The key never leaves.
- Custody platformThe transfer is sentConfirmed on chain.Does not happen: the pending transaction is cancelled.Only after the co-signer signs.
Multiple checks on the code.
Attackers now come through the code and the people who ship it. In this design, code reaches production only after a signed build, an independent review, a CVE scan and a quorum's approval.
Built: every image's build record and CVE report are signed by the build pipeline. Design: the rule that refuses a release missing any of them, and a quorum's hold on each release through signing displays.
Trusted from server to screen, by design.
- ✓Your app, policy and keys, on Secure Core
- ✓The co-signer is designed to sign only what people approved
- ✓Designed so that a breach in between cannot change what runs
In this run you approved the request, as a simulation: in the design, the co-signer signs only after that second hold.In this run you declined: nothing was signed, and in the design nothing leaves the vault.No decision was made in this run; the close describes the design, not an outcome.
This walk-through is an illustrative design demonstration. Nothing in it is connected to a custody platform, a customer or a live asset, and no outcome is guaranteed. What is built today is the signing display's rendering and hold on a bench prototype, the proved approval rule, and the build pipeline's signed records; the rest is design under review.
Illustrative design demonstration. Not connected to any partner, customer or live asset.
Illustrative design demonstration · Not connected to Fireblocks or live assets · The device shown is a design, not a shipped unit · No approval, signature or transfer leaves this page.