Team treasury

Set up a smart account where one team member requests a payout, a different member approves it, and a broadcaster submits signed approvals.

Where: Discover → Treasury, then Policies and On-chain access · You need: three or four wallets on Sepolia, test ETH, optionally a test ERC-20

Goal

Nobody can clear a payment alone. A requester proposes a transfer, an approver reviews it, and the on-chain policy refuses anything that skips a step or goes to an address that is not on the list.

Who is involved

Duty	Role in the Platform	Example
Configures the account, approves as a fallback	Owner (protected role)	0x3B9d…A41e
Starts payout requests	TREASURY_REQUESTER (custom role)	0x8C4e…21bB
Approves or cancels requests	TREASURY_APPROVER (custom role)	0xD27a…f9E3
Submits signed approvals and pays gas	Broadcaster (protected role)	0x5E60…c7D1
Emergency fallback	Recovery (protected role)	0xF01c…9aB4

Time: about 45 minutes on Sepolia.

Before you start

• Read Designing roles and permissions once. It explains why requester, approver and broadcaster are separate wallets.
• If real people will hold these roles, read Organization governance too. It maps each duty to a job title and covers onboarding, offboarding and review.
• Fund the owner wallet and the broadcaster wallet with Sepolia test ETH. Both pay gas.
• Collect the payout addresses you will allowlist (for example two vendor addresses).
• You do not need an account for any of this. Sign in if you have early access; otherwise join the waitlist from the same dialog. A paid organization adds a shared account list, and on Pro, watched addresses and alerts. Neither changes the on-chain policy below.

Phase 1: Deploy and set the Security baseline

1. On Discover, choose Treasury and select Start Treasury Operations.
2. In Deploy Smart Account, name the account (for example Operations Treasury) and select Continue.
3. On Protocol Security, set Owner (your admin wallet), one or more Broadcaster addresses, Recovery, and a Time-lock (for a treasury, 1 Days is a sensible start; 1 Hours is fine for the test). Select Deploy Smart Account and confirm.
4. Inside the account, open Policies → Security and confirm the four settings. Use Add broadcaster if you need a second one later.

The account lands as a Vault (what that means). Every preset deploys the same governed account today; the treasury behaviour comes from what you configure next.

Phase 2: Confirm the actions

1. Open Policies → Actions.
2. Confirm NATIVE_TRANSFER (__bloxchain_native_transfer__()) is listed. Every account registers it at deploy, so there is nothing to add.
3. For token payouts, confirm ERC20_TRANSFER (transfer(address,uint256)) is listed. It is registered at deploy too.
4. Both rows read Flow incomplete. Nothing is wrong: the functions are registered, but no role may use them and no destination is allowed. Add action is for your own functions, such as mint(address,uint256), and is not needed for payouts.

Both transfer operations are registered at deploy. Flow (1) is where you check them: it reads incomplete until permissions, gates and allowlists exist, and lists the paths once they do.

Phase 3: Create roles and add signers

1. Open On-chain access → Roles and select Create role.
2. Create TREASURY_REQUESTER with Max wallets 3, then TREASURY_APPROVER with Max wallets 2. Set the maximum a little above the number of people you have today.
3. Open each role, select Manage role signers, and add the wallet addresses. Sign the batch.

Roles shows how many signers each role holds against its limit, and how many actions it may perform. AUDITOR (1) has none.

You can also work from the other direction: Signers → Add signer → pick roles for one address.

Phase 4: Manage permissions per path

Open Policies → Actions, select NATIVE_TRANSFER, then Manage permissions. The editor has one tab per execution path. Fill in the two you want and leave the third empty.

Tab	Request step	Approval steps	Execute step
Delayed release	TREASURY_REQUESTER	TREASURY_APPROVER (Approve and Cancel)	performed by the approver's on-chain approval
Signed approval	TREASURY_REQUESTER	TREASURY_APPROVER (signs approval or cancellation off-chain)	Broadcaster
One signature	leave empty	leave empty	leave empty

1. On Delayed release, at Request select Assign role → TREASURY_REQUESTER. At the Approval steps assign TREASURY_APPROVER. Owner stays as a fallback.
2. On Signed approval, assign TREASURY_REQUESTER to Request, TREASURY_APPROVER to the Approval steps, and Broadcaster to Execute.
3. Review the Governance flow card, then sign.
4. Repeat for ERC20_TRANSFER.

The Governance flow card shows which role can perform each step on each path.

Leaving One signature empty means no single wallet can request and approve in one go.

Phase 5: Grant gates

1. Open Policies → Gates. The Needs attention view lists every role that has access on Actions but no gate yet.
2. Select Edit, turn on the gates for TREASURY_REQUESTER and TREASURY_APPROVER, then confirm in Update gates and sign.
3. The header should read All gates granted, and the Actions page should no longer show Gates mismatch.

The page says it plainly (1): a gate is permanent for that role. Plan gates with the role, not per request.

Phase 6: Allowlist payout recipients

1. Open Policies → Allowed recipients and select Add recipient. Add each payout address. Sign the batch.
2. For ERC-20 payouts, open Allowed contracts and add the token contract as a destination with transfer(address,uint256) as its assigned function.

Only these addresses appear in the Recipient picker when someone creates a request.

Phase 7: Test with three wallets

1. Fund the account: Assets → Receive, send a small amount of Sepolia ETH.
2. Requester (0x8C4e…21bB): select New request → Transfer, choose the native asset, a small amount and an allowlisted recipient. Try both methods:

   • Wallet → Submit request: the request is posted on-chain and waits for the time lock.
   • Sign → Sign request: the request is posted and can be approved by signature.
3. Approver (0xD27a…f9E3): open Approvals. For the delayed request, wait until State reads Ready, open it and select Approve. For the signed path, open the request, switch the toggle to Sign and sign the approval. It moves to the Approved tab.
4. Broadcaster (0x5E60…c7D1): on the Approved tab, open the signed transaction and select Execute.
5. Check History: both requests show Executed. Check My access with each wallet; it should list only the phases you intended.

The Approvals queue is where the approver works.

1. Negative test: with the requester wallet, try a request to an address that is not allowlisted. It does not appear in the picker, so the request cannot be built.

Operating rhythm

• Approvals is the daily queue. Approvers work the Pending tab; broadcasters work the Approved tab. There are no status filter chips on this page, so use the tabs and the search box. Delete signed items whose deadline passed without submission.
• History is the ledger. Group by Requester or Result for a monthly review, and filter Cancelled and Failed to see what was stopped.
• When a person leaves, remove their address from the role in Roles. When a duty changes, edit Manage permissions, not the person. Organization governance has the full onboarding and offboarding checklist, including rotating the Broadcaster and clearing gates.
• If the team runs on a paid organization, add each signer under Settings → Organization → Member addresses so names appear beside addresses in shared views. Plans are named in Organizations and billing; pricing is shown at checkout or on request.

Checklist

• Requester, approver and broadcaster are three different wallets
• NATIVE_TRANSFER (and ERC20_TRANSFER, if used) showing ready, not Flow incomplete
• Delayed release and Signed approval configured; One signature empty
• All gates granted
• Every payout address allowlisted; token contract allowlisted for ERC-20
• One delayed and one signed request executed end to end
• Backup exported from Settings → Backup

Related

• Manage permissions
• Gates
• Allowlists
• Approvals