Plan-Sign-Execute
Every operation that moves funds (earn, withdraw, transfer) follows a three-step flow. This keeps Legend non-custodial — your users’ keys never touch our servers.The three steps
1. Plan
Your server tells Legend what you want to do:plan_id— A temporary identifier (valid for 2 minutes)chart— The transaction detailschart.eip712_data.digest— The hash that needs to be signed
2. Sign
The account’s signer (an EOA private key or Turnkey-managed key) signs the EIP-712 digest. This proves the key holder authorizes the transaction. The signing happens entirely on your side — Legend never sees the private key.3. Execute
Your server sends the signature back to Legend:status: "executing" and can monitor progress via the activities or events endpoints.
Why this pattern?
Non-custodial security. Legend constructs transactions but can never submit them without signer approval. Even if an attacker compromised a query key, they couldn’t move funds — they’d also need the signer key. Transparency. The plan step lets you (or your user) inspect exactly what will happen before committing. The EIP-712 typed data is a standardized, human-readable description of the transaction. Flexibility. The signer can be:- An EOA private key your server holds (for fully automated flows)
- A Turnkey-managed key (for programmatic access with hardware-level security)
- Presented to an end-user for manual approval (like a wallet confirmation)
EIP-712 signing
EIP-712 is an Ethereum standard for typed structured data signing. It produces signatures that are:- Bound to a specific contract — Can’t be replayed on a different contract
- Bound to a specific chain — Can’t be replayed on a different network
- Human-readable — Wallets can display what you’re signing
chart.eip712_data contains:
| Field | Description |
|---|---|
digest | The final hash to sign (this is what you pass to your signer) |
domain_separator | Identifies the contract and chain |
hash_struct | Hash of the structured transaction data |