The whole book, one screen.
Wallets, policies, approvals, sessions, and audit in one console. Operators see assets, exposure, and activity at a glance.
Every wallet, every chain, one view.
Wallets grouped by chain with their policy attached, across DeFi wallets, perp DEX accounts, and exchange accounts.
- Grouped by chain, policy visible per wallet
- DeFi, perp DEX, and exchange accounts in one list
- Search by name, address, wallet id, or tag
Trade by hand or algorithmically.
The console is where both modes meet. FortkeyLink for discretionary trading, the Rust SDK and REST API for algorithmic flow, one set of keys and policies across both.
- FortkeyLink for manual trading on any DEX
- Rust SDK and REST API for bots
- One policy engine across both modes
use fortkey_hft_sdk::{bytes_to_hex, BotTrader, TxKind, UserId};
#[tokio::main]
async fn main() -> anyhow::Result<()> {
// Challenge-response auth with your bot key. No static API keys.
let pem = std::fs::read_to_string("bot-key.pem")?;
let mut sdk = BotTrader::new(pem.trim(), UserId::new("us-mm-eu-01")?)?;
sdk.login().await?;
// Pin an enclave co-located with your venue, then open a wallet session.
sdk.use_signing_instance("eu-central-1", None, None, None).await?;
sdk.start_wallet_session("mm-eu-perps", "eu-central-1").await?;
// Your strategy builds the order; Fortkey signs it inside the enclave.
let order: Vec<u8> = build_order();
let sig = sdk.sign_tx("mm-eu-perps", &order, TxKind::EvmEip712).await?;
println!("signature: {}", bytes_to_hex(&sig.to_der()?));
sdk.logout().await?;
Ok(())
}Approvals that cannot be self-approved.
Sensitive changes require m-of-n sign-off. Requests carry their full context, and the requester can never approve their own change.
- m-of-n quorums on sensitive changes
- Comments, rejects, and full request context
- No self-approval, by design
Audit you can hand to anyone.
Every action lands in the log with who, what, when, IP, and status. Sessions are visible and revocable in one click.
- Complete action log, filterable and exportable
- Sessions with expiry and one-click invalidation
- Customer-owned audit trail
Trading separated from administration.
Role-based access per user, group, and wallet keeps who can trade apart from who can administer.
- Access per user, group, and wallet
- Trader, admin, and read-only separation
- Address books usable directly in policies
{
"name": "John Smith",
"email": "john@fortkey.io",
"type": "TRADER",
"role_id": "ro-0000000000-24df859c3f1268f38aad",
"login_rule": {
"whitelisted_ips": [
"203.0.113.0/24"
]
}
}A real-world use case
An approval request that carried its own context
A desk added a new trader through the console. The request required a second approver, could not be self-approved, and landed in the audit log with who, what, when, and status.
Policies and approvals
Create rules, simulate transactions against past traffic, and require m-of-n quorum sign-off for sensitive changes — no self-approval, by design.
Wallet operations
Organize wallets by chain, venue, desk, or strategy, and maintain controlled address books that plug directly into policy rules.
Access and sessions
Define roles per user, group, and wallet, scope access precisely across trading and administration, and revoke active sessions in one click.
Audit and reporting
Filter the full action log by who, what, when, IP, and status, and export operational records for internal or external review.