By default, all payments that come in to a Juicebox project issue tokens. These tokens are distributed to a beneficiary specified by the payer, and to any addresses specified in the project's reserved token list. The amount of tokens minted depends on the amount paid and the weight (i.e. exchange rate) of the project's current funding cycle. Projects can override or extended this default behavior using data sources.
By default, the protocol allocates tokens to recipients using an internal accounting mechanism in JBTokens. These are fungible but do not conform to the ERC-20 standard, and as such cannot be composed with ecosystem ERC-20 marketplaces like AMMs. Their balances can still be used for voting on various platforms.
Projects can issue their own ERC-20 token directly from the protocol to use as its token. Projects can also bring their own token as long as it conforms to the IJBToken interface and uses 18 decimal fixed point accounting. This makes it possible to use ERC-1155's or custom tokens.
Once a project has issued a token, token holders can claim tokens from the protocol's internal accounting mechanism in JBTokens to their wallet to use across the Ethereum global computer.
By default, tokens can be cashed out by holders to reclaim a portion of what's in the project's surplus. The amount of surplus claimable is determined by the cashOutTaxRate of the project's current ruleset. Projects can override or extend this default behavior. Cashing out tokens burns them, shrinking the total supply.
A project owner can issue and distribute more of the project's tokens on demand. This behavior must be explicitly allowed on a per-ruleset basis.
A project can use its tokens however it wishes. It can be purely ceremonial, used for governance, used for airdrops, or whatever.
Tokens can be issued on-demand by project owners or their operators by calling JBController.issueTokensOf(...). The ability to do so must be explicitly turned on via a ruleset configuration metadata parameter.