Push Offers (Fireblocks / Safe)

Bridge facilitations require real-time communication with signatures to create and cancel offers. Fireblocks (and similar custody) doesn’t expose the EIP-712 signing primitive we need, so we have a workaround: a whitelisted EOA signs once to generate an API key, and that key drives all subsequent offer activity. Your Fireblocks (or Safe) address is then bound to the API key and is the address that holds the resulting positions.

This is a five-phase flow. Phases 1 and 2 are one-time setup.

Phase 1 — Create and whitelist your signing EOA

Spin up a fresh EOA with any wallet (MetaMask, Rabby, etc.). Security here doesn’t matter much — the EOA only signs the API-key generation message; it never holds funds. Just make sure you control it.

Send the EOA address to the 3F team for whitelisting. You can’t move on to Phase 2 until the address is whitelisted.

Phase 2 — Generate an API key and bind your Fireblocks address

After whitelisting:

Connect the whitelisted EOA in the console (see Getting started).
Go to the Auctions tab and start a push offer flow. The console pops an auth gate dialog asking how you want to authenticate — pick the API key path (skip the EIP-712 sign-in option).
The dialog routes you to the Settings tab → Push Offers card. Initially the card shows “API key — not set”, “Facilitator (EOA) — —”, and “Offer address (Safe) — required before push offers”.
Switch your wallet to Ethereum mainnet (chainId = 1). The BF API requires the API-key signature on mainnet regardless of which network you’ll operate on. The Push Offers card surfaces a Switch to mainnet button when you’re on the wrong chain; the Generate API key button stays disabled until your wallet is verifiably on mainnet (we don’t auto-switch because some wallets ack the switch before their actual eth_chainId flips, which breaks the typed-data sign).
Click Generate API key and sign the EIP-712 GenerateFacilitatorApiKey message in your wallet. The new key appears once in a yellow reveal banner labeled “New API key — copy now, it cannot be recovered”. Copy it somewhere safe before clicking Hide — once dismissed the key can only be regenerated, not recovered.
Paste your Fireblocks (or Safe) EVM address into the Set offer address field at the bottom of the card and click Save. The address is validated client-side (must be a valid 0x… 20-byte address) and the Save button stays disabled until the input is valid.

After saving, the Offer address (Safe) row at the top of the card shows your bound address with a copy affordance. The address is read live from the BF API on every page load — if you set it from another device or it’s rotated server-side, the console picks up the change automatically.

Phase 3 — Make offers

Open the Auctions tab. The table lists every auction (active + terminal) with columns for ID, vault, amount requested, blended rate, direction (Sub / Redemption), term (T+N), and status (LIVE, PENDING, EXPIRED, etc.). Click a column header to sort.

Click any LIVE row to open the offer form drawer. Fill the two inputs:

Principal — the amount you want to lend, in USDC (or whatever the auction’s deposit asset is). The MAX button auto-fills the auction’s full requested amount; over-offering is allowed (the protocol only pulls what’s needed) and the form will show a soft warning when you exceed the requested amount.
Yield (bps) — the non-annualized yield in basis points. Auctions are 1-day for now, so 100 bps = 1% over the auction duration. Sub-bp precision is supported (e.g. 3.5).

Click Submit. Because you have an API key configured, the form skips the wallet signing path entirely — there’s no per-offer EIP-712 prompt and no ERC-20 approval. The offer is posted directly through the API and a success toast confirms the new offer ID.

Multiple offers per auction are allowed.

The offer immediately appears in the Live Offers section of the User tab with a PUSH badge next to its SUBMITTED status (so you can tell at a glance which offers came through the API key path versus a per-offer signature).

To cancel, see Managing offers. Push offers cancel instantly through the API key — no wallet prompt.

Phase 4 — Provision matched offers

Once an auction closes and your offer is matched, it moves from SUBMITTED to AWAITING_MINT. You’ll find it on the User tab in the Pending Settlement section.

Provisioning means executing one approval + one mint per matched offer from your Safe / Fireblocks / Fordefi. The recommended path is the dedicated Request Push UI at request-push.3f.xyz — connect the offer-address wallet (WalletConnect for Fireblocks/Fordefi, Safe Apps iframe for Safe) and click Mint on each pending row. The page batches approve + mint into one signature when your wallet supports EIP-5792, and falls back to two sequential prompts otherwise.

If you’d rather drive the mint from your custody UI’s existing Transaction Builder, the main console can still build a Safe-compatible JSON batch you import manually.

See Mint & Claim (request-push) for the recommended path, or Provisioning matched offers for both options side-by-side.

Phase 5 — Claim repaid bridges

When an auction repays, your bridge becomes claimable. The recommended path is again the Request Push UI: connect the offer-address wallet, click Claim on each row in the Claimable proceeds table, and a burnAll lands the principal + interest back in the offer address.

Alternatively, the main console can build a Safe burn batch JSON for import into the Transaction Builder.

See Mint & Claim (request-push) for the recommended path, or Claiming repaid bridges for both options.

TL;DR checklist

Phase 1 — Create EOA, send address for whitelisting.
Phase 2 — Connect EOA, switch to mainnet, generate API key, save Fireblocks address.
Phase 3 — Submit offers from the Auctions tab (no per-offer signing required).
Phase 4 — Mint matched offers from request-push.3f.xyz with your offer wallet (or export the Safe TX JSON from the console).
Phase 5 — Claim repaid bridges from request-push.3f.xyz (or export the Safe burn JSON from the console).