Account groups

You are looking at an old version of this page: revision #7 by zoobc.how, 2026-10-26 20:39 UTC. See the current version

An account group is one account that can be reached at many addresses. A phone wallet, a hardware wallet and an Ethereum browser wallet can all be members, and a payment to any of them lands in one shared balance. One member, the controller, manages the group and decides what each other member may spend. This makes family and company accounts possible, with a spending allowance for each person or device.

One account, many addresses

The group's balance, its tokens and everything else it owns live on a keyless group address, derived from the transaction that founded the group:

group address = 00000000 ‖ SHA3-256( "ZBC-GROUP" ‖ founding transaction hash )

Nobody holds a key for it. Every member address resolves to it: a payment to any member is credited to the group, and asking for any member's balance returns the group's. Each address keeps its own nonce.

A keyless group address holding one balance, surrounded by a controller, a member who may spend and a receive-only member; a new address joins and everything moves in, an old one leaves as a fresh, empty address

A group holds up to 100 addresses, the controller included. Members may be of any key type that can sign (ZooBC, Bitcoin, Ethereum, Solana and the others; see keys and account types), and a multisignature account can be a member too.

Joining

Only the controller links a new address, with LinkAccount, and only with that address's consent: a signature over a chain-bound digest tagged "ZBC-GROUP-LINK", valid for at most 5,760 blocks (a day) ahead and usable once. The consent can be the address's own signature, a multisignature account's threshold of signatures, or an Ethereum personal_sign.

Joining moves everything the address owns into the group, up to 1,000 items: its balance, tokens, issued tokens, datasets, files, triggers, schedules, offers, orders, sponsorships, and node and service registrations.

Among the addresses that cannot join are:

a group address;
an address that already belongs to a group, since each address can be in only one;
an address with a split policy;
an active node, gateway, relay or archival key;
the release authority.

Leaving and handing over

A member leaves with UnlinkAccount and takes nothing with it: the address starts again as a fresh, empty account. Whatever it brought in stays with the group.

The controller cannot leave before handing over control. TransferGroupControl passes control to another member, who must consent with a signature tagged "ZBC-GROUP-CONTROL"; the old controller then becomes receive-only.

Permissions

A new member is receive-only: it can receive payments for the group and it can leave, but it cannot spend. The controller changes that with SetMemberPermissions:

bit 0: the member may spend ZBC;
bit 1: the member may move the group's tokens (this needs bit 0 as well);
a ZBC limit per period, the period being from 1 to 2,102,400 blocks (a year); a limit of 0 means no limit.

A limit of 5 ZBC per 5,760 blocks, for example, is a daily allowance of 5 ZBC.

Some actions belong to the controller alone: LinkAccount, SetMemberPermissions, TransferGroupControl, SetSplitPolicy and SetTransactPolicy. A group's split policy applies to money sent to any member (see split and transact policies).

The group pool with the controller holding full rights, a padlock over link, set permissions and hand over control, and members tagged receive-only, may spend without limit, may spend 5 ZBC per 5,760 blocks, and may move tokens

How limits are enforced

A member's limit is a consensus rule, not a wallet setting:

at admission, a node works out the most ZBC the transaction could take from the group (the amount, the fee, any survival deposit, and an escrow's commission and rent) and refuses it if that exceeds what is left of the member's window, counting the member's other pending transactions;
when a limited member's transaction runs, it runs inside a savepoint: the chain measures what the group's balance really lost, and if that passes the limit, the transaction is undone;
a block that carries a denied member transaction is invalid on every node.

Each member has its own slot under the rule of one transaction per account per block, because each signs with its own address.

Tokens and rent

A token issued by a member belongs to the group, and any member enabled to send for the group may later mint it (see minting and burning tokens).

The group pays account rent and pruning like any account, plus storage rent on its record: 96 bytes and the controller's address, plus 40 bytes and the address of each member. Members pay no rent of their own. A group that cannot pay is dissolved, and its leftover dust goes to the longevity pool (see ZBC is never burned).