Folks holds client funds in an omnibus account custodied by Fireblocks, and wants to allocate into Pods yield strategies. This page maps the flow of funds for each integration model, so profit stays attributable and custody stays with Folks.
Both keep custody with Folks and isolate yield per position. They differ in where the individual wallet lives and whether bytecode is ever signed. Step through the diagram — each step animates one movement of funds or one API interaction.
Folks creates one Smart Wallet (a Gnosis Safe) per user, owned by a dedicated Fireblocks vault — the Vault Owner (we call it the Pods Signer) — which acts as the signer for all Smart Wallet transactions. Folks stores the mapping of which user owns which Smart Wallet address. Pods returns transaction data / bytecode to be signed by the Vault Owner — the omnibus account never signs bytecode, it only ever does plain transfers.
POST /fireblocks-smart-account with owner (the Vault Owner vault address) and chainId. One dedicated Fireblocks vault owns all Smart Wallets (Gnosis Safes). Pods returns the deployed Safe’s address; Folks stores the relation: which user owns which Smart Wallet address.smartWalletAddress created in step 1.GET /strategies/:id/bytecode with action=lend, wallet, amount and output=fireblocks. Pods responds with transactionData — ready to submit directly to the Fireblocks API.transactionData.transactionRequest with the Fireblocks SDK — fireblocks.transactions.createTransaction() — signed by the Vault Owner (see the Fireblocks integration docs). The signature represents an investment directly into the yield strategy.Why a Smart Wallet instead of investing from the vault directly? Fireblocks doesn’t work well with Multicall / gas sponsorship, so each user gets a Smart Wallet (Gnosis Safe) owned by a dedicated Vault Owner — which also provides security segmentation, keeping the Omnibus signer from ever being exposed to potentially malicious bytecode. And since the signer is the dedicated Vault Owner — never the omnibus — the omnibus account only ever performs plain transfers.
A transfer-only, deposit-address model: one Fireblocks sub-account (segregated vault) per user. Pods hands back a deposit address; the omnibus does a plain transfer to it, and Pods delivers the yield token (aToken) straight into the user’s Fireblocks sub-account. No arbitrary bytecode execution anywhere — it’s just a transfer.
GET /strategies/:id/bytecode with the user’s Fireblocks sub-account as destinationAddress. Pods responds with a deposit address — nothing to sign.No bytecode, no signer setup: this is pure transfers — no Vault Owner, no Smart Wallet deployment. The only requirement is one Fireblocks sub-account per user to receive the aToken. Track via GET /wallets/<fireblocks-sub-account-address>.
The context, the two hard constraints, a side-by-side of the paths, and the API surface, condensed so the flows above stay the main story.
A single Fireblocks omnibus account funds everything; the goal is to allocate into Pods yield (e.g. Aave).
Yield tokens must land in an individual wallet so each position’s profit stays fully attributable.
The omnibus account never signs arbitrary bytecode. Anything leaving it is a plain transfer; contract calls are signed only by the dedicated Vault Owner vault.
The destination token (e.g. aToken) is received into an individual wallet, enabling per-position balance, profit and history.
wallet, amount + output. Returns a deposit address (Option B) or, with output=fireblocks, transactionData ready for the Fireblocks API (Option A).owner (the Vault Owner address) + chainId. Option A only.