Verification Council

The 3F Verification Council is the group of independent organizations that jointly hold critical ownership of the Grunt protocol. It is composed today of 3F, ChainSecurity, Aragon and Steakhouse Financial.

The goal is simple: no single part of the protocol is owned by 3F alone. Each member controls its own signer account, and those accounts are the signers of the multisigs that own the protocol. No member holds another member’s keys, so every privileged action requires at least two independent organizations to agree before it can be executed on-chain.

How It Is Structured

Ownership is split across four Safes, each with a 2 of 3 threshold and each scoped to a different part of the protocol. Splitting them keeps day-to-day operations (unblocking a fund subscription, granting an operational role) separate from the actions that can change contract code, and lets each set of decisions be reviewed by the members best placed to judge it.

Multisig	Signers	Scope	Address
Admin	3F, ChainSecurity, Aragon	Beacons and proxy admins, through a 24 hour timelock	`0xA9F5...bA24`
Position Manager Owner	3F, Aragon, Steakhouse	Position Managers and wrapped assets	`0xA0f6...FD26`
Facility and Funds Owner	3F, ChainSecurity, Aragon	Facility, Funds, TransferGuards, Retargetters	`0xf1C6...147b`
Repayer	3F, 3F Foundation, Aragon	Attesting loan repayment on Request contracts	`0xe1dD...0cb5`

flowchart LR
    ADMIN["Admin Safe (2/3)"] --> TL["Admin Timelock (24h)"]
    TL --> BEACONS["Beacons & proxy admins"]

    PMO["Position Manager Owner (2/3)"] --> PM["Position Managers"]
    PMO --> WA["Wrapped assets"]

    FFO["Facility & Funds Owner (2/3)"] --> FAC["Facility"]
    FFO --> FUNDS["Funds"]
    FFO --> TG["TransferGuards"]
    FFO --> RT["Retargetters"]

    REP["Repayer Safe (2/3)"] --> REQ["Request contracts"]

Admin

The Admin Safe is a 2 of 3 between 3F, ChainSecurity and Aragon. It is the only body that can change the code the protocol runs, and it does so through the Admin Timelock at 0xC1ab...6fA5, which owns the upgradeable beacons and the proxy admins.

Upgrades are therefore a two-step process. The Safe first proposes an operation on the timelock, and the operation only becomes executable 24 hours later. Nothing about a deployed implementation can change without that delay elapsing in public first, which gives integrators and depositors a window to inspect a pending upgrade and react to it.

The Admin Safe is the only holder of the timelock’s proposer, canceller and admin roles. Execution once the delay has elapsed is open to a second operational account, which is a convenience only: an executor can run a pending proposal but cannot create one, change one, or shorten the delay.

ChainSecurity, the firm that audits the protocol, is a signer on this Safe, so the party that reviews the code is also on the path that ships it. See Audits for the published reports.

Position Manager Owner

A 2 of 3 between 3F, Aragon and Steakhouse Financial. It owns every Position Manager and every wrapped asset, and it is the only body that can enable transferability on a wrapped asset.

Its responsibilities cover the parameters and permissions of the leverage containers themselves:

Granting and revoking roles on the Position Managers (curator, rebalancer, minter).
Adding borrow modules and setting the LTV and fee parameters of a Position Manager.
Enabling transferability on a wrapped asset.
Configuring the shared BorrowOffersRegistry used by the borrow positions, which holds the proposer and guardian roles and the per-collateral settings behind offer pre-liquidation.

Facility and Funds Owner

A 2 of 3 between 3F, ChainSecurity and Aragon. This is the operational ownership Safe, and it covers the widest surface:

The Facility: granting the facilitator role, and the other operational roles on the intent lifecycle.
The Fund contracts: unblocking subscriptions and redemptions of the underlying RWAs when an external protocol settles in an unexpected state, and granting the depositor and settler roles.
The TransferGuards enforcing compliance on Position Manager and wrapped asset transfers, including the compliance role that maintains blocklists and whitelists.
The Retargetters, the contracts that automate leverage retargeting. Owning one means setting its sizing and repayment configuration, whitelisting the funds and flash-loan modules it may use, binding it to a Position Manager, and granting its rebalancer and consumer roles.

None of these permissions can mint value or move user funds on their own. They configure who is allowed to operate the protocol and unblock flows that external settlement has stalled. The full list of roles per contract is on the Roles page.

Repayer

The Repayer Safe is a 2 of 3 between 3F, the 3F Foundation and Aragon, with a different signer set from the other three Safes. It exists for one job: attesting that a bridge loan has been repaid on a Request contract.

It carries more automation than the other Safes, because repayment attestation is a high-frequency, checkable fact rather than a judgement call:

3F produces a signature attesting the repayment of a loan on the Request contract.
Aragon picks it up and counter-attests through an automated service run by the DAO, which independently verifies the parameters of the loan, the amount repaid and the duration.

The automation covers the normal path only. Exceptional situations, such as a possible default or a late repayment, are handled manually by Aragon, 3F and the 3F Foundation. Nothing in that path is automated.

Guardians

Separate from the Verification Council, 3F runs a distributed attestation service called Guardian. Where the Council owns the protocol, the Guardian signs off on individual operations at execution time.

The Guardian attests three kinds of action:

The pricing of cross intent swaps.
The whitelisting of Request contracts.
The binding of a Request or a Fund contract to an intent.

It is currently run by 3F and Aragon, and both signatures are required for any of these operations to proceed. The requirement is enforced on-chain rather than by convention: the Facility verifies the EIP-712 guardian signatures against the intent’s configured quorum before executing a swap or a binding, and the Request Whitelist verifies a validator quorum of signatures before flipping an attestation. See Roles for the on-chain role, and Guardian Coordinator Setup for the operator side.

What This Means for Integrators

Every privileged action on the protocol needs two independent organizations, drawn from a set of four, to sign.
Implementation upgrades are additionally delayed by 24 hours and are visible on-chain before they can execute.
The signer set differs per scope, so a single compromised organization cannot take control of any part of the protocol.
Every address above is verifiable on-chain. The owner of any contract can be read directly with owner(), and the Safe signers with getOwners().

The canonical addresses for the contracts these Safes own are listed on the Deployments page and published as JSON at /deployments.json.

Announcement

The Council was announced on July 31, 2026.

Introducing the 3F Verification Council 🔍 We're excited to welcome @AragonProject, @SteakhouseFi, and @ChainSecurity as members of the 3F Verification Council. The Council is an independent verification layer built into 3F. By requiring external review and co-signatures…
— 3F (@3f_xyz) July 31, 2026