If an LLM agent is going to move your USDC, give it something that can say no.quant-transfer-guard (QTG) is an open-source control plane that sits between your trading strategy — or your agent — and an actual transfer. It compiles movement requests into audit-logged execution graphs across CEX accounts and EVM chains. Self-hosted. Your KMS, your DB, your callbacks. No hosted control plane in the path.
Three promises
QTG is organized around three orthogonal product promises. Everything else is in service of one of them.Movement approval before dispatch
Movement/template requests stop at
PENDING_APPROVAL unless an explicit, template-scoped auto-approve policy matches. The destination address is re-checked against the allowlist at dispatch time — revoking an address actually stops the next withdrawal. Provider-internal capital transfers are a separate Pro, default-off immediate-submit surface; they are not movement approvals.Keys across a process boundary
For EVM movement lanes, Core uses nonce-HMAC
RemoteSignerProxy to call a private signer service that owns the AWS KMS configuration. qtg.main rejects in-process local and extra signer settings. Local signer inputs are for explicitly documented tools, not the Core runtime.Agentic-safe by design
3-role RBAC (admin / operator / agent). Agent keys are bound to a scoped agent authority — they can propose templates inside that binding, but cannot approve, rotate signers, or change allowlists. MCP server + agent CLI make this usable from Claude Desktop / Cursor / Agent SDK.
Operational discipline
Exchange API drift
Upbit, Bybit, OKX return undocumented state strings. Every adapter is fixture-first and case-insensitive — parser changes ship with a real-response fixture or they don’t ship.
Audit by default
Every state transition is appended to
audit_events. Every outbound callback is HMAC v3 signed with nonce replay defense and dispatched from a durable outbox.Local-first
No telemetry. No hosted control plane. Self-hosted: your KMS, your DB, your callbacks.
Quickstart that just works
EVM RPC endpoints for ~24 chains pre-populated via PublicNode defaults.
cp .env.example .env and the dev quickstart works without hunting for RPC URLs. See reference/rpc-defaults.Supported venues
CEX Lane
3-node pipeline:withdraw → withdraw_observe → deposit_observe via exchange API.
Pro adds Bithumb and Backpack (CEX), provider-internal capital operations, CCIP, USDT0, Stargate, and Lighter under the commercial license. Installed code is not evidence that a specific venue, account, or route is ready for live use.
Bridge Lane
On-chain KMS-signed execution via smart contract or protocol API.
The table describes implementation ownership, not a claim of route-specific live proof. Every operational route still needs its configured credentials, signer, allowlist, policy, and operator evidence before use.
Using QTG from an LLM agent
QTG ships three entry points so an LLM agent can drive the control plane without shell access:qtg-mcp does a boot-time whoami check and refuses to start if the key role isn’t agent or the env namespace doesn’t match the server-reported namespace — so a misconfigured key won’t quietly land in Claude Desktop.
Full reference: CLI & MCP. For delegated USDC spend by the agent’s session, see Agent Wallet Top-Up.
Quick start
Local setup
Get QTG running locally with Docker Compose
First movement
Create and execute your first dry-run movement
Template cookbook
Design DAG templates for your transfer routes
Going live
Production setup with real credentials and KMS
What this is not
- Not a custody solution. Hold the keys yourself; QTG signs through your KMS.
- Not a trading engine. Hummingbot, NautilusTrader, your own bot — they decide what to send. QTG decides whether to let it.
- Not a hosted SaaS. There is no JephaLabs control plane on the runtime path.
- Not a defense against a compromised host. QTG’s guards run inside its own process. Read Security Tradeoffs for where that line falls before you point it at real funds.