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"
]
}
}In practice
A stolen laptop, revoked in one click.
A trader's laptop disappeared on a train. From the console, the security team revoked every session and wallet permission for that user in one click; the audit log confirmed nothing had been signed since the last legitimate order, and the whole incident was reconstructable, minute by minute.
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.