Move value. Move data. On your terms.
A ZooBC transaction is a signed envelope wrapping a small typed body. The envelope is identical for every type — the body and a few optional modifiers decide what actually happens: a plain send, a token transfer, a vested salary, an escrowed deal, an app move, a scheduled trigger. This is the full map.
01Anatomy of a transaction
Everything is serialized little-endian into one byte buffer, then signed. The blue fields are the envelope (same for all types); the purple body is what changes per type.
An account address is 4-byte type (LE) + public key — 00000000+32B ed25519 for ZBC, 04000000+ETH, 05000000+BTC, and so on. A missing recipient is written as the empty type 02000000. The message tail is where a plain send carries its memo — the body of a SendZBC is only the amount; the recipient and memo live in the envelope.
02Signing
The account type decides both the address prefix and the signature scheme. Sign over the whole envelope (without the signature field). All three are deterministic, so a browser wallet and the node agree byte-for-byte.
ZooBC (ed25519) · type 00000000
// digest, then sign digest = SHA3_256(txBytes) sig = ed25519(digest, privkey) // 64 bytes
Also the scheme for Solana, Cardano, Tezos, Polkadot — same ed25519 key, different address prefix + display encoding.
Ethereum (secp256k1) · type 04000000
// recoverable ECDSA, low-s digest = keccak256(SHA3_256(txBytes)) r,s,v = secp256k1.sign(digest) sig = r ‖ s ‖ (v+27) // 65 bytes
MetaMask can also send its own signed RLP; the node recovers the sender and maps it to a ZBC transfer.
Bitcoin (secp256k1) · type 05000000
// double-sha over the SHA3 payload digest = SHA256d(SHA3_256(txBytes)) sig = secp256k1.sign(digest) field = [len(2)] ‖ compressedPub(33) ‖ sig
Fee, in short
The minimum fee is size-aware: a base rate × the network fee-scale, plus a per-byte storage/duration component. Read it live from /api/v1/fee-params or price an exact tx with /estimate-fee so the wallet never disagrees with the node to the atomic unit. Overpayment on a precise-fee send is refunded.
03The three kinds of coin
Amounts are always atomic (1 ZBC = 100,000,000). The only thing that changes between coins is the token_id field — the movement mechanics are identical.
① Native ZBC
token_id = 0 everywhere. The gas/fee coin, block rewards, staking. A SendZBC (type 1) is the plain path.
② Genesis / bridge tokens
Wrapped foreign assets minted at genesis (ZBTC, ZETH, ZSOL…). They are ordinary colored tokens with a fixed token_id assigned in the genesis config — nothing special at the protocol level.
③ User-issued tokens
Anyone mints one with IssueToken (type 10): symbol, supply, decimals, optional ZBC backing. Its token_id derives from the issue tx. Same TransferToken / MintToken / BurnToken apply.
Wherever a body has a token_id (transfer, swap, app stake, liquid, vesting…), pass 0 for ZBC or the token's id for a colored coin. Backed tokens can even pay their own fee (a fee_in_token flag), priced against their ZBC backing.
04Modifiers — one payment, many shapes
Beyond the base types, three timing/trust wrappers change when and whether funds actually land. They are what make the surface feel large.
Escrow
Append an escrow section to any value tx's envelope (approver · commission · timeout · instruction). The funds are held until the named approver signs ApprovalEscrow (type 4) to release or reject — or the timeout expires. A conditional deal on top of any transfer.
Liquid
LiquidPayment (type 6): a single delayed payment over a window. The recipient is paid the full amount when the window completes, or a pro-rata slice if the sender LiquidPaymentStops (type 262) early. Short-term (hours), ZBC or token.
Scheduled / Vested
ScheduledTransfer (type 29): release in tranches on a timer — vesting (funds pre-locked) or recurring salary (pulled each period). Cliff, revoke, recipient-decline, reassign. Long-term (weeks–years). The releases show up as ledger movements, not new txs.
Trigger / Stop
The lightweight timer: CreateTrigger (15) locks an amount to fire at a future height; CancelTrigger (16) refunds it. To stop the long ones: CancelSchedule (30) revoke/decline, LiquidPaymentStop (262).
They stack. A monthly salary that is also escrowed, a vesting grant in a colored token — the primitives compose. (Full composition of recurring-with-escrow is on the roadmap; the building blocks are all here today.)
05Keeping data-objects alive
On-chain objects that hold data — datasets (key/value profiles, chat, business forms) and tokens — pay rent to persist. "Adding funds to an object" means topping up its survival financing.
Datasets & files → prepaid storage
You write data with SetupAccountDataset (type 3, a property → value pair) or store a file with DFSCreateFile (8). Each block bills storage rent against your account's prepaid storage; when it runs dry the object is pruned. Top it up with AddPrepaidStorage (type 9) — body is just an amount, credited straight to your prepaid-storage balance. More prepaid = longer life.
Tokens → persistence financing
A colored token also pays to survive. FinanceToken (type 14) tops up a token's persistence horizon from the fee — extending how long it stays live before its unused backing is returned to the creator. Same idea, per-token.
06Full transaction catalog
All 50 transaction types, with their exact little-endian body layout. coin = supports token_id · modifiable = accepts an escrow section · new chain = consensus-level (ships with a chain launch).