Signing

Audience: Anyone signing on-chain transactions through Overledger. Reading time: ~8 minutes. Prerequisites: Chapter 6: Flow Applications if you plan to use the Signer Flow App. You'll learn: Account models per DLT, the two key-custody options (you hold the keys vs Quant holds them on your behalf) and how each one surfaces during the Sign phase of Prepare-Sign-Execute, and key-hygiene guidance.

All Flow App signing flows through the built-in Signer Flow App (mechanics in section 6.2). What that means in practice depends on where the signing-key material is held: if you hold the keys, the Signer renders a typed Wallet field and your client signs; if Quant holds them on your behalf (testnet hot wallet, or contracted mainnet KMS / HSM), the Signer signs internally and you see no Wallet field. Either way the Gateway and the calling Flow App never see private-key material. This chapter covers DLT account models, both custody options, and key-hygiene guidance.

7.1 DLT account models

Different DLTs model accounts differently. The Overledger Gateway normalises a few common operations (balance, transfer, history) but signing rules remain native to each DLT.

The Overledger Firewall Connector layer operates on the API key of the caller, not on the underlying chain address, so the same key can sign with multiple chain accounts. The on-chain Fusion Firewall sub-component then enforces against the chain address(es) the API key has been bound to.

7.2 Bring your own signing (SDKs, wallets)

This is the path when you hold the signing keys yourself, browser wallet, library SDK, hardware wallet, your own KMS / HSM. When a Flow App reaches its Sign phase, the Signer Flow App (section 6.2, Under the hood, the Sign hand-off) cannot produce the signature itself, so it renders a typed Wallet field carrying the unsigned transaction. Your client (the Quant Connect UI's wallet component, your direct-HTTPS / SDK code, or your MCP host) surfaces that field to the signer you have configured, you approve the signature, and the signed bytes go back to the Signer step. The Gateway never sees the private key.

The same path applies to raw RPC calls outside any Flow App, sign locally and submit through /rpc/{apiKey} or the Connectors RPC.

The alternative, asking Quant to hold the key material on your behalf so the Signer can sign internally, is covered in section 7.3.

Browser wallets

For EVM chains including Fusion Rollup, any wallet that speaks EIP-1193 works: MetaMask, Rabby, Coinbase Wallet, Frame. Point the wallet at the Gateway's RPC URL and your wallet signs as it normally would.

🚧

Warning, RPC URL is a credential

The URL contains your API key. Anyone with the URL can submit RPC traffic under your identity. Don't log it, paste it in chat, or commit it.

7.3 Custody & key hygiene

The same principles apply to every key your Overledger client touches:

• Never check keys into version control. Use environment variables in development, a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) in production.
• Use distinct keys per environment. Dev, staging, and production must have different signing keys. The blast radius of a leaked dev key should never include mainnet funds.
• Prefer KMS or HSM custody for mainnet. Either through the Signer Flow App's production mode or through your own custody (Fireblocks, AWS KMS, Azure Key Vault, hardware wallets).
• Mirror resource history for audit. GET /users/me/history returns combined deposit + swap history. For broader coverage (Flow App sessions, contract calls), mirror the relevant /users/me/* resource endpoints to your own log store.
• Rotate keys after suspected exposure. Regenerate your Overledger API key (3.3) and rotate any on-chain signing keys whose use is correlated with the leak window.