Docs · Products
The organization treasury
Receiving into an address your organization controls, and sending from it under policy.
Which treasury this is
The balance at the address your organization's signing key controls. Not the network's community pool, which belongs to the chain and is spent by governance and consent together. One word, two objects — and this is yours.
It is not a new kind of thing. A treasury is an account: an address that holds a balance, signed for by the same key, held in the same custody, bound to the same tenant as everything else your organization signs. There is no treasury key, no treasury module and no treasury role.
Receiving
Send coin to the address and it arrives. There is nothing to enable, nobody to tell, and no feature involved — an address is an address. What the Console owes you is showing which address, in full and copyably.
Check the address before sending to it. A transfer to a mistyped address is a transfer, and nothing in Bengar or on the chain can recall it.
AVAILABLE See the organization's treasury address and balance — /projects/[projectId]/treasury
Where: Console → Assets → Treasury
First: An organization signing key, provisioned on the Assets page.
Requires: ADMIN, AUDITOR
Sending, and why holding the key is not permission
Your organization's key can sign. That is a capability, not a decision. Every transfer passes a conjunction first, decided by the backend and decided again at the moment of signing — because state moves between a review and a confirmation, and the second decision is the one that governs.
| Check | Applies | What it does |
|---|---|---|
| Role | yes | ADMIN, from the canonical table. No new role was invented. |
| Policy | yes | Your organization's own policy, evaluated per transfer. This is where a treasury bound lives. |
| Risk | yes | The same deterministic scorer the agent path uses. |
| Approval | where required | A policy or risk REQUIRE_APPROVAL raises an obligation, discharged by a signed approval under separation of duties. |
| Permit | no | A permit is a delegation. An organization moving its own treasury delegates to nobody, so none is presented and none is checked. |
The review names every check, including the one that does not apply — and says *not applicable* rather than *passed*. A check reported as passed when it never ran would tell you a control protected you when it was never consulted.
AVAILABLE Send from the organization's treasury — /projects/[projectId]/treasury
Where: Console → Assets → Treasury → Review transfer
First: A signing key, a funded account, and a policy that allows the transfer. Holding the key is not permission.
Requires: ADMIN
What a policy can and cannot say about a treasury
It can gate a transfer by who is asking, when, and which treasury — an organization with two projects has two, and they are named apart. It can require an approval or refuse outright.
It cannot gate by amount. A money comparison must name an ISO 4217 currency, because comparing minor units across currencies is a real vulnerability rather than a rounding concern — and a chain denomination is not a currency in that sense. A rule that tried would not validate, and the transfer would be denied rather than silently allowed.
That limit is recorded rather than worked around. Lifting it means deciding how a money comparison may name a denomination without reopening the cross-currency hole, which is its own decision.
What gets signed
One immutable intent, fingerprinted over the recipient, the amount, the denomination, the source account, the chain, the sequence, the fee and the gas — and over your organization, so two organizations sending an identical transfer have different fingerprints. The confirmation carries only the fingerprint; there is no field in it that could change what you reviewed.
- Committed — in a block, with a height and a hash.
- Refused — the chain rejected it. Nothing moved.
- Unknown — nobody knows yet. It is not a failure, and there is no retry.
There is deliberately no control that resends an UNKNOWN transfer. One that timed out may already be in a block, and sending it again is how one payment becomes two.
Agents and the treasury
An agent may request an action. A permit may bound what an agent requests. A permit does not grant access to an organization's chain signing key.
There is no route — direct, indirect, or triggered automatically by a permit — from an agent to a signature by your organization's key. The treasury is behind a human session; an agent holds a machine credential, which is a different door, and no route bridges them.
That bounds what a stolen permit is worth. It lets an attacker ask, against policy, risk, approval and a budget. A permit that could sign would let them spend, and every control in front of it would be advisory.
NOT AVAILABLE Let an agent spend the organization's on-chain funds
Deliberately outside v1, and not a missing feature. An agent may request an action and a permit may bound what it requests; a permit does not grant access to an organization's chain signing key, and there is no route — direct, indirect or automatic — from one to the other. A permit that could sign would be a bearer instrument for whatever the key can do. Whether an agent should ever move on-chain funds is a separate decision with its own threat model.