Facility

The Facility is the central contract in the Grunt protocol. It manages intents — on-chain work orders that define and enforce how capital moves from user deposits through leveraged strategies and back to claims. Every major operation in the protocol flows through the Facility.

What Is an Intent?

An intent in Grunt is a fully on-chain work order. It is not an off-chain intent that gets picked up by a solver or matched in a mempool. It is a concrete, on-chain data structure that specifies exactly what the Facility is authorized to do with the capital deposited into it.

Each intent defines:

• Deposit asset — the token that liquidity providers contribute during the deposit window. This can be a simple token like USDC, or a Position Manager whose shares represent leveraged exposure (e.g., USCC 2x)
• Target asset — the asset the intent aims to produce. Like the deposit asset, this can be a simple token or a Position Manager. The target asset is mutable — if the target Position Manager gets liquidated, the facilitator can point the intent to a fresh Position Manager and continue the process
• Deposit cap — a maximum on total deposits to control the size of the strategy
• Deposit close — a maximum timestamp after which no more deposits or withdrawals are accepted. The facilitator can choose to start the resolve phase earlier
• Compliance rules — which TransferGuard governs the LP tokens
• Whether LP tokens are transferable — some intents lock LP tokens to prevent secondary trading
• Quorum — the number of guardian signatures required for sensitive operations such as swaps between intents, setting the Fund contract, and setting the Request contract

An intent may also be bound to at most one Fund (for async settlement) and at most one Request (for bridge facilitator financing). These bindings are exclusive — a Fund or Request assigned to one intent cannot be reused in another.

The Three Lifecycle Phases

Every intent moves through three phases in order. There is no going back.

1. Depositing

This is the entry phase. The intent is open for business.

• Liquidity providers deposit the specified asset and receive ERC-6909 LP tokens in return, minted 1:1 with their deposit amount
• LPs can also withdraw during this phase, burning their LP tokens and receiving their deposit back 1:1
• Deposits can be reverted if a user turns out to not be authorized for compliance reasons
• The facilitator can adjust the deposit cap
• No fund operations, request operations, or position manager operations are allowed yet

The depositing phase ends either when the facilitator explicitly locks the intent or when the configured deposit close timestamp is reached.

2. Resolving

This is the execution phase. Deposits and withdrawals are closed. The facilitator now has access to the protocol’s building blocks to execute the strategy:

• Fund operations — create, commit, unlock, or recover orders on the bound Fund wrapper (subscribing to or redeeming from the underlying async protocol)
• Request operations — pull bridge loan capital from the bound Request or repay it
• Position Manager operations — depositing and withdrawing collateral, borrowing and repaying debt on the target Position Manager
• Swap operations — move balances between intents, subject to guardian approval via EIP-712 signatures
• Deposit reverts — if the intent still holds enough of the deposit token (at least the original deposited amount), deposits can be reverted for users who are no longer authorized for compliance reasons

The facilitator composes these building blocks according to the strategy. For example, a typical leverage flow would pull bridge capital from the Request, commit it along with user deposits to the Fund, wait for settlement, deposit the resulting collateral into the Position Manager, borrow to repay the bridge loan, and prepare for resolution.

The resolving phase can only end when there are no active Fund orders and any bound Request has been fully repaid.

3. Resolved

This is the distribution phase. The strategy has been executed, and the intent now holds the resulting tokens (which might be Position Manager shares, leftover deposit assets, or both).

• LP token holders can claim their pro-rata share of everything the intent holds by burning their LP tokens
• Claims can be partial — an LP can burn some tokens now and the rest later
• A claim returns a list of tokens and amounts, reflecting whatever the intent accumulated during resolution

Once resolved, there is no further Facility intervention. The intent is purely a distribution mechanism.

What LPs Do

Liquidity providers are the users of the protocol. Their interaction is simple:

1. Deposit during the depositing phase — send the deposit asset, receive LP tokens
2. Wait while the facilitator executes the strategy during the resolving phase
3. Claim during the resolved phase — burn LP tokens, receive a proportional share of the resulting assets

LPs do not need to understand the underlying strategy mechanics. They deposit capital, and the LP tokens they hold represent their claim on whatever the strategy produces.

What the Facilitator Does

The facilitator is the operational role that drives intent execution. It is not a user — it is typically an automated system or a privileged operator role.

The facilitator:

• Creates new intents with the appropriate configuration
• Locks intents to close the deposit window when ready
• Executes the sequence of Fund, Request, and Position Manager operations that implement the strategy
• Resolves intents when all operations are complete

The facilitator has significant operational authority, but it is bounded by the intent’s configuration. It cannot change the deposit asset, exceed the deposit cap, or resolve an intent while a Fund order is still active or a Request is unpaid.

Guardrails

The Facility enforces several safety properties:

• Constrained facilitator — the facilitator has operational authority but is significantly constrained. Value-changing operations such as swaps, setting the Fund contract, and setting the Request contract require guardian signatures meeting the intent’s quorum. Request repayments are checked through multisignatures to prevent under- or over-repayment
• Fund and Request exclusivity — each Fund and Request instance can be bound to at most one intent, preventing cross-contamination between strategies
• LP token transfer controls — LP tokens can be configured as non-transferable at the intent level, and are always subject to the TransferGuard attached via the guard key
• Phase enforcement — operations are only available in their designated phase; the contract rejects any operation that does not match the current state
• Global pause — the entire Facility can be paused as an emergency safety mechanism

ERC-6909 LP Tokens

Each intent is identified by a numeric ID, and LP tokens for that intent are tracked using the ERC-6909 multi-token standard. This means:

• A single Facility contract can manage many intents, each with its own token ID
• LP token balances, approvals, and transfers all follow the ERC-6909 interface
• Metadata (name, symbol, decimals) is provided by a separate descriptor contract
• The same compliance rules (TransferGuard) that apply to other tokens in the system also apply to LP tokens