Mint & Claim (request-push)

For push offers, the recommended way to mint matched authorizations and claim repaid proceeds is the dedicated Request Push UI at request-push.3f.xyz. Connect the wallet that holds the offer address (your Fireblocks, Fordefi, or Safe), and the page lists everything you can act on with one button per row — no JSON export, no Transaction Builder hop.

It complements the main console: the console is where you submit and manage offers; Request Push is where the offer-address wallet ratifies the on-chain steps (mint, burnAll).

When to use it

You want to	Use
Submit, cancel, or watch offers	The main console at 3f.xyz — see Push offers.
Mint matched push authorizations	Request Push (this page).
Claim repaid push bridges	Request Push (this page).
Mint or claim from a custody UI without connecting it directly	The console’s Safe TX JSON exports — see Provisioning and Claiming.

Connecting your offer wallet

Open request-push.3f.xyz and click Connect Wallet. The dialog lists wallets in two sections:

• Connect with — every injected/MIPD wallet the browser exposes (MetaMask, Rabby, etc.). The most recently used connector gets a Last used badge.
• Other wallets — WalletConnect (QR code) and Porto (passkey).

The Safe connector auto-activates only when the page is loaded inside the Safe Apps iframe. So:

• Fireblocks / Fordefi — connect via WalletConnect. Scan the QR (or pair through your custody’s WalletConnect integration). Both use whatever path their interface exposes for arbitrary dApps; nothing 3F-specific is required.
• Safe — open request-push.3f.xyz as a custom app inside app.safe.global (Apps → custom app → paste the URL). The Safe connector will pick up automatically and any transaction you submit becomes a Safe proposal that follows your normal threshold.
• EOA / browser wallet — pick it from the Connect with list.

The connected address is the address the page reads against. Connect the same EVM address you set as your offer address in the main console’s Settings → Push Offers. If you connect a different wallet, both tables will be empty even when you have pending mints or claims.

The app is mainnet only — there’s no network toggle. If your wallet is on a different chain you’ll be prompted to switch when you submit.

Page layout

A single page with two tables:

Pending mints

Auctions where you have a pending mint authorization. Approving + minting in one batch when your wallet supports it.

Each row shows:

• Auction — vault display name + #id + direction (Sub / Redemption).
• State — the off-chain auction status (DEPOSIT_READY, PROCESSING, PARTIAL_SOLVED, or SUCCEEDED). All four are valid states for a row to be mintable, depending on whether the relayer has caught up.
• Request — the request contract address, truncated.
• PT — principal you’ll receive, in the deposit asset (USDC, etc.).
• YT — yield share you’ll receive, in the same asset.
• Action — a Mint button.

Rows surface when request.mintAuthorization(connectedAddress) returns non-zero PT for an auction in one of the candidate states above. The query polls every 30 seconds. If a row you expect isn’t there, either the auction hasn’t been authorized for your address yet, or you’ve already minted and the authorization is now zero.

Claimable proceeds

Repaid auctions where you still hold PT/YT shares. Claim with burnAll to receive the underlying assets.

Same column layout (PT / YT now show your current balances), with a Claim button. Rows surface when the auction is in REPAID status and request.balancesOf(connectedAddress) returns non-zero PT or YT. Same 30-second poll cadence.

After the burnAll lands and your balances drop to zero, the row drops out on the next refetch.

Mint flow

Click Mint on a row. The button submits two calls as a single batch via EIP-5792 (wallet_sendCalls):

1. approve(requestId, ptAmount) on the deposit-asset ERC-20.
2. mint(maxPt = ptAmount, minYt = ytAmount) on the request contract.

maxPt and minYt come straight from mintAuthorization — minting consumes exactly what was authorized.

Wallet behavior:

• EIP-5792 wallets (Safe, Porto, modern injected wallets) prompt once for the bundle and broadcast it atomically.
• Non-5792 wallets fall through to viem’s automatic fallback: two sequential eth_sendTransaction prompts — sign approve, wait, then sign mint.
• Fordefi — the page ships a manual fallback for a known viem 2.48.x crash where Fordefi’s error shape (no details field) breaks the automatic fallback. You should still see two sequential prompts, just routed through the manual path.

A success toast surfaces the transaction (or batch) ID with an explorer link. Failures surface an error toast and emit a PostHog event tagged deposit / mint.

For Safe connections, the “transaction” is a proposal — it lands in your Safe queue and waits for the rest of your signers. The row stays in Pending mints until the Safe transaction executes on-chain.

Claim flow

Click Claim on a Claimable proceeds row. The button submits one call:

• burnAll(owner = connectedAddress, receiver = connectedAddress) on the request contract.

Both arguments are the connected wallet, so the proceeds land back in the offer address. There’s no input to fill — burnAll always burns the full PT + YT balance and pays the corresponding pAssets + yAssets.

A success toast surfaces the tx id. A PostHog event tagged claim / burnAll is emitted on failure.

For Safe connections, again, this becomes a queued proposal.

Operational notes

• The page never asks for an API key, EIP-712 signature, or BF API call. It’s a thin on-chain client — mintAuthorization, balancesOf, asset, and the two write functions are the only contract interactions.
• Re-clicking Mint after a successful submit is safe but pointless: mintAuthorization will return zero on the next poll and the row will disappear.
• Re-clicking Claim after a successful burnAll will revert on-chain because there’s nothing left to burn — the row also drops out on the next poll, so this is rare in practice.
• The auction list under the hood is GET /v1/auction?scope=all against the BF API. You don’t need credentials for this read.
• The page is mainnet-only; there’s no Sepolia/testnet variant of request-push.*.

When the rows are empty

Symptom	Likely cause
Both tables empty after connecting	You connected a wallet that isn’t your offer address. Disconnect and reconnect with the right one.
Pending mints empty for an offer you just won	The relayer hasn’t called authorizeMinting yet. Wait 30 s for the next poll, or refresh. Status is still SUBMITTED / pre-DEPOSIT_READY.
Claimable proceeds empty for a bridge that should be repaid	The auction hasn’t transitioned to REPAID yet, or you’ve already claimed. Cross-check the main console’s Open Bridges.
Row shows but Mint errors immediately	Authorization may have expired or been overwritten. Refresh, then read mintAuthorization directly to confirm the current PT/YT.