3F Grunt

The following protocol assumptions and behaviors are known and out of scope. Reports that rely solely on violating the assumptions below, or on the protocol behaving exactly as described, will be rejected unless the report demonstrates a new independent impact outside these assumptions.

The scope only includes the smart contracts in the provided repository. Websites, APIs, and any other off-chain components are out of scope.

For generic exclusions, see the Cantina Bug Bounty Out-of-Scope Policy.

Privileged Roles and Governance

• Protocol owners, proxy admins, beacon owners, request owners, wrapped-asset owners, transfer-guard owners, deployers, and equivalent governance/admin roles are trusted. Reports that require any of these roles to be compromised, malicious, or incorrectly operated are out of scope. This includes contract upgrades, role grants/revocations, oracle configuration, transfer-guard configuration, request repayment signoff, and deployment/initialization mistakes.
• Fund Operators are trusted operational roles and are expected to be multisigs, not EOAs. Reports that only show an Operator can cause loss or liveness failure by using intended emergency powers such as resolve(), recovering(), cancelRequest(), or forceEnd() are known. This includes the accepted risk that forceEnd() may abandon pending or committed asynchronous assets in edge cases.
• The Facilitator, Rebalancer, Curator, Consumer, and MorphoFlashLoanRequest Executor are semi-trusted operational roles. Reports that only show these roles can cause liveness failures, poor routing, delayed deployment, unfavorable leverage, bad queue ordering, or other bad-but-authorized operational choices are known. The EXECUTOR_ROLE on MorphoFlashLoanRequest should be treated as having Facilitator-level trust for the intents it operates on.
• Guardians are trusted signers. Reports that require guardians to sign malicious, stale, or economically bad approvals are out of scope. Guardian signatures are treated as live authorizations until their deadline, and guardians are expected to use short deadlines and verify the current intent/request/fund state before signing.
• Guardian quorum may intentionally be zero for some intents. For quorum-0 intents, the Facilitator has unchecked power over the intent. Reports relying only on quorum being set to zero are known unless they affect a non-zero-quorum intent or bypass a separate protection.

Component Selection and Factory Provenance

• The protocol assumes operators/facilitators only wire approved Grunt components and approved external venues. Factory registries and deployment tracking are used for monitoring and integration tooling, but not every trust decision is enforced by an on-chain factory check. Reports requiring a trusted role to deliberately attach a malicious non-approved Fund, Request, PositionManager, TransferGuard, wrapper, oracle, market, or script are out of scope unless the report shows the address can be introduced without violating that operational assumption.
• Multiple factories may exist. Reports that only argue a component is not from one specific factory, without showing it bypasses the approved deployment/monitoring process, are known.
• Removed or deprecated factory entries may remain queryable. Reports that old factory-registered components stay discoverable or cannot be retired are known unless they show an active unauthorized binding path.

External Protocols and Off-chain Settlement

• Centrifuge, Pareto, Superstate, Morpho Blue, Chainlink, USDC, and supported upstream contracts are trusted within their documented behavior. Reports requiring these protocols, their admins, their oracles, their upgrade paths, their allowlists, or USDC's peg to fail are out of scope.
• Centrifuge and Pareto are assumed to behave according to their documentation and not introduce reentrancy or breaking upgrades. Reports that depend on an upstream upgrade changing core behavior, token addresses, reentrancy properties, or documented settlement semantics are out of scope.
• Centrifuge and Pareto settlement is asynchronous and operationally managed. Delays, partial fills, stale virtual prices, epoch timing, queued cancellations, and similar RWA settlement behavior are known. Reports that only show assets can be delayed, dust can remain pending, or an operator must manually recover/resolve a small residual are known.
• The team or Centrifuge are responsible for calling notifyDeposit / notifyRedeem and managing Centrifuge pool-side state. Reports relying only on these calls not being made, or on Centrifuge pool-side state remaining unprocessed, are known liveness/operations issues.
• Centrifuge allows third parties to create requests for the fund controller, and this is an acknowledged integration risk. Reports based only on external users influencing controller-level pending/claimable state, donating to the controller, or polluting Centrifuge controller queues are known unless they show a new impact that does not rely on that upstream behavior.
• Pareto vaults must be integrated only after the first lending cycle / first epoch assumptions are satisfied. Reports relying on epoch-zero behavior or first-cycle edge cases are known.
• Pareto borrower default is an external credit/default risk. Reports that only show loss or locked value due to the Pareto borrower failing to repay, without a separate Grunt-specific bypass, are out of scope.

Fund Accounting, Slippage, and Residual Balances

• Fund order.output is not a strict on-chain final-settlement guarantee for every async integration. It may be checked at creation or used as an expected value, while final settlement can depend on off-chain/RWA processes. Facilitators/operators are expected to check rates and decide whether to commit, cancel, resolve, recover, or force-end. Reports that only show rate drift between create/commit/unlock, or missing final output validation in an async fund, are known.
• USCCFund is a rolling adapter with one active order at a time and balance-sweeping semantics. Late, residual, or excess USCC/USDC balances may be swept into the active order rather than strictly attributed to the historical order that generated them. Reports that only require strict per-order USCCFund balance attribution are known.
• USCCFund.totalAssets() is wrapper-wide, not per-fund. Reports that only show totalAssets() includes global wUSCC supply across multiple fund instances are known.
• USCCFund oracle pricing is intentionally approximate. Reports relying only on Chainlink freshness/precision for totalAssets() or output validation are known unless they show an exploitable path beyond the accepted oracle-margin model.
• Fund-level events are intentionally partial. Reports that only ask for additional Facility-level events for commit, unlock, recover, or cancel are out of scope.

Request, PT/YT, and Bridge-loan Lifecycle

• repaymentDeadline must be set far enough in the future for the strategy to repay before maturity. Reports that require an underfunded Request at maturity, late settlement after maturity, or a too-short maturity window are known unless they demonstrate a separate bypass.
• The Request deadline unlocks PT/YT withdrawals even if the Request was not economically repaid. Reports that only show the Request's maturity auto-sync is used as a repayment signal are known.
• After repaymentDeadline, normal Request repayments are closed. Reports relying only on late funds arriving after the deadline and not being payable through the normal repay() path are known.
• Request funding and utilization are intentionally non-strict phases. mint() / consume() may remain available after capital has been pulled, and the design allows increasing borrow amount rather than enforcing a hard funding-to-utilization state boundary.
• Request pull/repay orchestration is trusted operational behavior. Reports that rely only on the Facilitator performing repeated pull/repay cycles, or on repayments being drawable again before final signoff, are known unless they show an independent violation of the intended min/max balance controls or guardian checks.
• PT/YT accounting uses live Request balances and live supplies. Reports that only show ERC-4626 view functions, PT/YT redemption quotes, or YT allocation can change during pulls, partial PT redemptions, direct transfers, or late repayments are known.
• YT may receive more than one unit of asset per unit of YT in late-repayment scenarios. This is intended behavior for late repayments and not a bug by itself.
• Mint authorizations are operationally managed. To safely update a mint authorization, the old authorization must be revoked and confirmed before setting a new one. Reports relying only on a stale or incorrectly updated mint authorization are known.
• Residual unbacked-YT edge cases are acknowledged. The mint-to-repaid delay mitigates last-minute minting, but edge cases around repayment timing and deadlines are accepted and are not bounty issues by themselves.

MorphoFlashLoanRequest and Scripts

• MorphoFlashLoanRequest is only intended to be used inside the flash-loan execution flow. It implements a minimal, non-standard subset of IRequest, and users should not expect all Request functions to behave like the canonical Request outside flash-loan execution.
• Whitelisted scripts are trusted and flexible. The script payload is not fully validated against every intended context; this flexibility is intentional. Reports that only show a misconfigured whitelisted script can operate on the wrong intent/facility, or that script payload validation is missing, are known.
• The MorphoFlashLoanRequest owner and executor inherit Facilitator-like trust assumptions. Reports requiring malicious owner-controlled scripts, malicious executor behavior within approved scripts, or rescue of dust held by the flash-loan helper are out of scope unless they exceed Facilitator-equivalent authority.

PositionManager, Bad Debt, Leverage, and Fees

• PositionManagers affected by bad debt are expected to be operationally abandoned or quarantined. Reports that rely on continuing ordinary deposits, withdrawals, burns, rebalances, or fee accrual after a borrow module is already underwater or bad-debt-affected are known unless they show a new impact before the bad-debt state is detectable.
• Zero-clipped NAV behavior is accepted as part of the current PositionManager model. Reports that only show deposits, withdrawals, burns, rebalances, fee accrual, or share pricing are distorted once a sleeve is underwater are known under the bad-debt operational playbook.
• Bad-debt cleanup is operational, not fully encoded on-chain. The expected process is to pause relevant flows, stop resolving new intents, remove damaged modules from routing queues, wait for liquidation/cleanup where relevant, and remove or abandon the damaged PositionManager/module.
• Management fees are intentionally approximate. Reports that only show management fees are computed from the current AUM rather than the precise historical AUM curve are known.
• Performance-fee treatment of losses/recoveries is accepted. Reports that only show performance fees ignore previous losses, recovery paths can be favorable/unfavorable to LPs or the protocol, or the fee model is economically imperfect are known.
• Direct Morpho donations or repayments can affect PositionManager accounting. Reports relying only on permissionless Morpho collateral donations, direct debt repayment on behalf of a sleeve, or the fee recipient receiving a cut of donated debt relief are known unless they bypass the accepted operational mitigations.
• Share-inflation mitigation is not perfect in every theoretical scenario. Reports relying only on already-known donation/share-inflation economics, especially where the attack requires compromised Facilitator cooperation, unseeded/fresh PM setup, or 18-decimal edge cases, are known.
• A protocol seed / first deposit and operational setup is assumed for PositionManagers where required. Reports relying on an unbootstrapped fresh PM are known unless they show the configured production bootstrap can be bypassed.
• Leverage may deviate from target and is operationally re-targeted. Reports that only show achieved leverage differs from intended leverage, or that privileged roles can affect leverage within intended operational bounds, are known.
• Queue behavior is intentionally curated and may require manual rebalancing. Deposits may route to supplyQueue[0], withdrawal behavior depends on curated queues, and rebalancing is expected to maintain target allocation. Reports that only show bad outcomes from poor queue curation or lack of timely rebalancing are known.
• withdraw() and burn() have different intended constraints. If a proportional withdrawal would fail because a position is above the PositionManager target LTV, callers should use burn() where applicable. Reports relying only on this difference are known.
• Last-shareholder and dust-exit edge cases are accepted. Reports that only show tiny debt/collateral dust, inability to perfectly exit the final wei, or small residual amounts are known.
• Pre-liquidation and liquidation are subject to live Morpho/oracle state. Reports that exact preLiquidate() inputs can be front-run by small state changes, oracle updates, or live position changes are known unless they demonstrate more than re-quoting/frontrunning risk.
• Pre-liquidation economics are intentional. Reports that only argue the pre-liquidation bonus is large, liquidation penalty is not reflected in NAV, or full pre-liquidation can deflate share price to zero are known.
• Morpho liquidity and supplier behavior are operational assumptions. Reports that only show Morpho suppliers can withdraw liquidity, causing bridge repayment or borrowing difficulties, are known and rely on external liquidity/incentive assumptions.

Tokens, Allowlists, and Transfer Restrictions

• Only standard supported ERC-20 tokens are in scope. Reentrant/ERC-777-like tokens, fee-on-transfer tokens, rebasing tokens, tokens with more than 18 decimals, tokens with multiple entrypoints, tokens with unusual wei value, and tokens that revert on large approvals are unsupported. Reports relying on unsupported or malicious token behavior are out of scope.
• There is no general on-chain token allowlist. Reports that only show a compromised trusted role can introduce an unsupported token are known; the operational assumption is that only supported tokens are used.
• wUSCC / USCC transferability depends on Superstate allowlisting. Reports that only show recipients, protocol contracts, liquidators, or claim receivers must be Superstate-allowlisted are known. Liquidators for wUSCC-backed Morpho flows are expected to be allowlisted before markets are opened.
• A restricted payout token may block claims. Reports that only show a user-specified receiver or claim path can revert because one payout token is restricted, blocklisted, or not allowlisted are known.
• TransferGuard checks sender and receiver, not the delegated caller. Reports that only show a blocked approved spender/operator can still move shares for non-blocked holders are known; users are expected to revoke approvals to untrusted spenders.
• TransferGuard rotation requires an off-chain migration/checklist. Reports that rotating a guard clears or changes blocklist/whitelist state are known.
• Compliance flows must be ordered correctly. revertDeposit() should be performed before blocklisting the user. Reports that only show a blocklisted user cannot be reverted without unblocking are known.
• Fee-recipient compliance changes must be ordered correctly. If a fee recipient will be blocked, it must be rotated before blocking; reports that only show blocking the current fee recipient can brick fee accrual/rotation are known.
• Receivers are assumed to be valid external recipients. Reports relying only on users or approved global operators selecting the Facility itself, zero-value sinks, or otherwise invalid receivers for withdraw() / claim() are known unless they show the receiver can be forced without authorization.

LP Deposits, Claims, Approvals, and UI/Integration Behavior

• LPs may receive assets other than the target asset in a resolved intent. Reports that only show a successful flow can resolve with deposit asset, target asset, PM shares, debt asset, collateral dust, or another tracked token are known.
• ERC-6909 per-intent approve() is not relied on for withdraw() / claim(). Global operator approval is the supported delegation mechanism. Reports that only show per-ID allowance is unusable for these actions are known.
• ERC-6909 transfers may be payable. Accidental ETH sent with share transfers is a known accepted consequence and is out of scope.
• Deposit caps can be griefed by capital that later withdraws. Reports that only show an attacker can temporarily fill depositCap and withdraw during the deposit phase are known; the team may use whitelist mode, monitoring, cap sizing, or early lock operationally.
• Claim token iteration and token-set size are operationally bounded. Reports that only show gas exhaustion from an excessive number of tracked tokens are known unless they show an untrusted party can create an unbounded token set under supported-token assumptions.

Deployment, Chain, and Miscellaneous Assumptions

• The protocol is designed for Ethereum mainnet. Chain-specific issues on other networks are out of scope unless that network is explicitly listed in the bounty scope.
• The deployment process is trusted to use the intended safe proxy deployment flow. Reports that only show unsafe manual proxy deployment, beacon-owner mistakes, or accidental admin-right loss are known operational/deployment issues.
• Descriptor and metadata changes are cosmetic. Reports that only show the descriptor can change while paused, duplicated descriptor logic, or metadata/UI inconsistencies are out of scope unless they affect funds or permissions.
• Gas optimizations, event completeness, NatSpec/interface wording, and documentation inconsistencies are out of scope unless they cause a concrete security impact. Known examples include Yul beacon deployment, duplicated code for readability, partial Facility events, and accepted interface-spec mismatches.

Standard out-of-scope items per the Cantina Bug Bounty Out-of-Scope Policy.