Bridge Facilitator Overview

Grunt is 3F’s solution for leveraging RWAs and asynchronous assets. Bridge facilitators in Grunt are not liquidity providers in a pool. They provide bridge loans — short-term capital advances that cover the settlement gap between a user’s deposit and the maturation of an asynchronous asset. Each bridge loan is scoped to a single on-chain Request contract deployed by the Facility, with deterministic funding, repayment, and redemption enforced entirely by smart contracts.

If you are integrating operationally, continue to Onboarding after this page. If you want the contract-level lifecycle and call sequencing, continue to Settlement.

What Bridge Facilitators Do

When the Facility needs to execute a leveraged strategy on an asset that does not settle atomically (e.g., subscribing to a tokenized treasury fund), it cannot wait days or weeks for settlement. A bridge facilitator steps in and fronts the capital so that the strategy can proceed immediately. The protocol then repays the bridge loan once the underlying asset settles and is posted as collateral to a lending market.

Bridge facilitators earn a return on the capital they advance. That return is agreed upon upfront through signed offers and represented on-chain as Yield Tokens (YT). The principal is represented by Principal Tokens (PT). Both are redeemable once the bridge loan is repaid.

This is structurally similar to how traditional bridge facilitators extend short-term financing to hedge funds — except here, the rules are enforced by contracts rather than legal agreements.

End-to-End Flow

The lifecycle of a bridge loan follows a strict sequence:

1. Request is deployed — The Facility creates a Request contract linked to a specific intent (e.g., “deposit into a 5x leveraged USCC Position Manager”). The Request defines the asset, the funding deadline, and the repayment deadline.

2. Bridge facilitators submit offers — Bridge facilitators sign EIP-712 typed data specifying the principal they are willing to provide and the return they expect. Offers are submitted off-chain to the Grunt auction engine.

3. Offers are consumed — The auction engine selects the best offers. The Request contract pulls funds from each BF funding address and mints PT and YT tokens as receipts. For a bridge facilitator providing 1,000,000 USDC with a 10% expected return, the Request mints 1,000,000 PT and 100,000 YT.

4. Facility draws funds — As the designated puller on the Request, the Facility transfers the bridge loan capital to execute the intended strategy (e.g., subscribing to an RWA fund).

5. Repayment — Once the underlying asset settles and the protocol borrows against it on a lending market, the Facility repays the Request.

6. Redemption — After repayment is marked complete, bridge facilitators redeem their PT and YT tokens for the underlying asset. PT covers the principal 1:1 (senior in the waterfall), and YT captures any yield above that.

RFQ-Style Quoting

Bridge facilitators provide liquidity through an RFQ (Request for Quote) model rather than a pool-based mechanism. Each offer is a signed message that fixes:

• Principal amount — the maximum capital the bridge facilitator is willing to advance
• Expected return — the yield the bridge facilitator requires on that principal
• Expiration — a timestamp after which the offer is no longer valid
• Nonce — a sequential value for replay protection and cancellation

This design means bridge facilitators retain full control over their capital until the moment it is consumed. There is no idle capital sitting in a contract waiting to be matched. Offers can be updated, replaced, or cancelled at any time before consumption.

The mechanism supports both EOAs and contract-based signers (including multisigs) via EIP-1271 signature validation.

Just-in-Time Settlement

Bridge facilitators often do not keep idle balances in the wallet they quote from. Capital may sit in lending markets, internal vaults, or custody adapters.

Grunt supports this through a callback mechanism. When an offer is marked with useCallback, the Request calls onRequestConsumed(...) on the maker’s address before pulling funds. This gives the bridge facilitator’s funding contract a hook to:

• Move funds from internal accounting or an external position
• Set the ERC-20 allowance for the Request contract
• Execute any preparatory logic needed to make the funds available
• Reject the fill entirely by reverting the transaction

This means a bridge facilitator can quote aggressively from a contract that manages capital across multiple venues, and only move the funds at the exact moment they are needed.

Smart Contract Guarantees

Every aspect of the bridge loan is enforced on-chain. There are no off-chain promises or manual settlement steps.

• Scoped usage — The Facility is the only entity allowed to draw down the bridge loan. It is configured as the Request’s puller at deployment and cannot be changed.
• Settlement ordering — An intent cannot be resolved (i.e., LP claims cannot be enabled) while its attached Request remains unpaid. User claims are gated behind bridge facilitator repayment.
• Transparent collateral — All assets held in the Request, the amounts pulled, and the repayment status are visible on-chain at all times.
• Deterministic redemption — PT and YT redemption values are computed by a formula defined in the contract. There is no discretionary distribution.
• No rehypothecation risk — Bridge loan capital is pulled directly into the Facility’s operational flow. It is not lent further or used as collateral by the protocol.

Next Steps

• Onboarding — Set up your BF identity, choose an operational funding address, and start managing offers.
• Settlement — Understand the on-chain call sequence, role boundaries, nonce management, and signer delegation.
• PT/YT Tokens — Learn how Principal Tokens and Yield Tokens represent your risk and return.