The agent
Custody & securityWaitlist
How the agent’s keys are meant to be held and what they are allowed to sign. This is the intended design. Deposits are not open.
The model
The agent needs to sign trades without anyone, including the agent itself, being able to sign anything else. The design separates the decision to trade from the power to sign: the agent proposes a transaction, and a signing layer with its own policy decides whether to sign it.
The planned signing layer is Turnkey: a delegated-access model where the private key never leaves a hardware-backed enclave. The agent holds an API credential scoped to signing only. A policy engine evaluates each request inside the enclave, so even a compromised agent host can only produce transactions the policy allows. The vendor is a design choice, not a promise; the commitment is the constraint, not the brand.
| Control | What it is | Status |
|---|---|---|
| Enclave signing (planned: Turnkey) | Agent key generated and held inside a hardware-backed enclave. The agent authenticates with a scoped credential that can request signatures; it can never read or export the key. | Waitlist |
| Enclave policy engine | Every signing request is evaluated inside the enclave against the policy before a signature is produced: allowlisted programs, bounded transfers, capped priority fees. | Waitlist |
| Treasury multisig (planned: Squads) | Funds not being traded sit behind a separate multisig that requires a team signature for any movement. The agent credential has no authority over it. | Waitlist |
| Withdrawal controls | Rules for moving funds out of the agent address, separate from trading permissions. | Roadmap |
| Attested agent logic | The decision loop itself running in a trusted execution environment, with remote attestation proving which build produced each trade. | Roadmap |
| External audit | Independent review of the signing and execution path, published in full. | Roadmap |
Key management
Three key tiers, by blast radius: the agent credential, which can only request signatures under policy; the trading key inside the enclave, which can sign but cannot move treasury funds; and treasury keys behind a Squads multisig, where any movement needs a team signature. Nothing held by the agent can drain anything.
What the signing policy enforces
- Program allowlist only: the Jupiter aggregator and the venues it routes through. Nothing else is signed.
- Bounded transfers: per-transaction lamport and token caps, matching the published position cap.
- Capped priority fees, so the key cannot burn the balance on fees.
- No arbitrary recipients: the trading path cannot send funds to unlisted addresses.
What is not decided
How outside capital would enter the agent, if at all, is not decided. No deposit mechanism exists. Any deposit design will be published here, labelled by status, before it opens.
Enclave signing, the policy engine and treasury multisig are the chosen design and open to the waitlist first; they are not built yet. Withdrawal controls, attested agent logic and an external audit are on the roadmap, with no date.