The DAO Treasury

A community DAO holds plain AE. There is no separate vault contract, no wrapped balance and no staking position. The treasury is the AE balance of the DAO contract, and the only way it leaves is a payout vote that passes and is applied in time.

Where the money comes from

Source	Amount	Path into the DAO
Buys on the bonding curve	0.5% of the curve value of every buy	`record_sale_transaction(buyer, buy_price)`
Opening a proposal	555 AE per vote opened	`add_vote(metadata)`, which is payable
A `ChangeDAO` migration into this DAO	The whole balance of the old DAO	`Chain.spend` from the old DAO

Nothing else pays the treasury. Sells do not, because the 1% spread is charged on the buy side; tips and posts do not, because they settle through Tipping_v3, not the token sale.

The DAO's share is not computed as a percentage. The sale sets the redemption reserve aside first and forwards what is left:

let reserve = state.bonding_curve.calculate_sell_return(state.token_contract.total_supply(), count)
state.dao_contract.record_sale_transaction(
  value = Call.value - overpaid_refund - affiliation_amount - reserve, protected = true, ...)

total_supply() has already been incremented by the mint, so reserve is exactly 0.995 × the curve price and the DAO receives the residual 0.5%. Setting the payout obligation aside before the treasury is paid is what keeps the reserve solvent.

The call is protected = true, so a DAO call that aborts does not block the trade; the AE stays in the sale contract. See Value flow and Fees & Slippage.

`record_sale_transaction`

stateful payable entrypoint record_sale_transaction(buyer: address, buy_price: int) : unit

The AE rides along with the call; the buyer's address and the buy price arrive as arguments. The stock DAO keeps the AE and does not store the arguments. Reconstruct which buys funded a treasury from the Buy events on the sale contract. The entrypoint is part of the ReplaceableDAO interface, so a replacement DAO can split income, forward part of it, or account for it per buyer. See Replaceable DAOs.

The token sale also calls record_sale_transaction with zero value and placeholder arguments as a probe, at deployment and on every set_beneficiary, to check the entrypoint exists. A DAO must accept zero-value calls to be a beneficiary.

The 555 AE is not refundable

The 555 AE paid on add_vote is a donation to the DAO. It lands in the treasury and no entrypoint returns it: not on rejection, not on expiry, and not on success. There is no refund, no cancel_vote and no author-only withdrawal.

A failed proposal costs its author 555 AE, which stays with the community.
The treasury grows every time somebody proposes something, whatever the outcome.
If a passed vote is not applied within the roughly two-day execution window, the 555 AE is still spent and the proposal has to be opened again at full price.

Read the balance

On-chain

The treasury is the AE held at the DAO's contract address. Take that address from the token's dao_address field, then look it up on æScan (opens in a new tab) or with your SDK's balance call for a contract address.

Everything else about the DAO is read through its entrypoints:

Read	Returns
`get_state()`	The whole `DAO.state` record
`votes()`	Every vote, keyed by sequential id, with an applied flag
`vote_timeout()`	The execution window, in key-blocks
`get_token()`	The community AEX-9 token contract
`get_token_sale()`	The sale contract this DAO owns
`get_community_management()`	The linked `CommunityManagement`, as an option
`factory()`	The factory that deployed it

Through the Superhero API

GET /api/tokens/{address} returns the token DTO, which carries the treasury directly:

Field	Meaning
`dao_address`	The DAO contract address for this token
`dao_balance`	The treasury balance, as a string in aettos
`sale_address`	The token sale contract, used as the route key in the app
`total_supply`	Needed to evaluate the 10% participation quorum
`holders_count`	How many addresses hold the token

dao_balance is in aettos; divide by 10^18 to get AE. See Tokens API for the rest of the DTO.

dao_balance is refreshed together with the token's live price, so it is as fresh as the last price refresh. For a balance consistent with a specific block (for example, when checking whether a VotePayoutAmount proposal is affordable), read the contract's account balance at that height yourself.

The treasury in the app

View	Route	What it shows
DAO list	`/trends/daos`	Every community DAO as a card: treasury balance, holders, creation date, market cap. Sortable and searchable.
One DAO	`/trends/dao/:saleAddress`	That community's treasury, its proposal list, and the create-vote form.
One proposal	`/trends/dao/:saleAddress/vote/:voteId/:voteAddress`	The ballot, the voters table, and the vote, revoke, withdraw and apply actions.

The DAO list is keyed by sale_address, not by the DAO address, because the sale contract is the stable public identifier for a community across the app.

What the treasury can be spent on

Only two of the seven vote subjects move money:

VotePayout(recipient) sends the entire DAO balance to one account.
VotePayoutAmount(recipient, amount) sends a specified amount to one account.

There is no multi-recipient payout, no streaming, no vesting and no budget primitive. A community that wants to split a grant between three contributors runs three proposals, or pays one address that then distributes off-protocol. A ChangeDAO vote also moves the whole balance, as part of a migration; see Replaceable DAOs.

Proposals and Vote Subjects: the two payout subjects and their exact parameters.
How DAOs Work: the funding step in the context of the whole lifecycle.
Replaceable DAOs: the interface record_sale_transaction belongs to.
Value flow: where the other 99.5% of a buy goes.
Tokens API: the full token DTO including dao_address and dao_balance.
Browse every DAO treasury (opens in a new tab): the live list.

How DAOs Work Proposals & Vote Subjects