Split and transact policies
Two account settings shape what reaches an account. A split policy forwards fixed shares of every incoming credit, in ZBC or in any token, to up to ten other addresses: royalties, revenue shared between partners, or automatic savings. A transact policy refuses whole categories of transactions in both directions, so that, for example, nobody can send the account unwanted tokens. Each is set with one transaction and stays until it is changed.
Split policy
A SetSplitPolicy transaction (type 54) lists up to 10 recipients, each with a share in basis points (100 basis points make 1 %):
- each share is at least 1 basis point, and all shares together come to at most 10,000 (100 %);
- no recipient may appear twice, and the account may not name itself;
- every recipient must be able to hold funds.
A body of 00 clears the policy.
What is split
The policy applies to every incoming credit, in ZBC and in tokens: payments, escrow releases, triggers, stream payouts, vesting payments, token transfers, trade fills, app payouts and rewards. It does not apply to refunds of the account's own money (such as an escrow returned to its sender), to pull-mode schedule payments, or to bridge mints.
Each share is floor(amount × basis points ÷ 10,000), and whatever is not assigned, rounding included, stays with the account. Shares do not cascade: a recipient's own split policy is not applied to what it receives through a split, so money cannot loop. A recipient whose transact policy refuses payments is skipped, and its share stays with the account.
In an account group, only the controller sets the policy, and the group's policy applies to money sent to any member. An address that has a split policy cannot join a group.
Transact policy
A SetTransactPolicy transaction (type 50) stores a 2-byte mask on the account. Each bit refuses one category of transactions in both directions: the account will neither send nor receive them.
| Bit | Category |
|---|---|
| 0 | Payments |
| 1 | Apps |
| 2 | Tokens |
| 3 | Exchange |
| 4 | Data storage |
| 5 | Escrow and multisignature |
| 6 | Node infrastructure |
| 7 | Bridge (AttestEvent) |
| 8 | Governance |
A few types are never refused: Empty, SetTransactPolicy, SetSplitPolicy, the longevity types and the account-group types.
How refusal works
A node refuses a transaction that a policy forbids as soon as it is submitted. If a block carries one anyway, it is bounced: the sender pays the fee and nothing moves. Only the recipient named in the transaction's envelope is checked, when the transaction runs. Payments that the chain makes later on behalf of an earlier transaction, such as schedule payments, trigger releases and stream payouts, still reach a recipient that has opted out.
A transact policy is not a fee setting, since fees follow from each transaction's floor, and it does not choose block producers, which the chain draws. For spending limits on the members of a shared account, see account groups.