Triggers and attestations

A trigger is a conditional payment held by the chain: ZBC locked now, released to a recipient later, when a condition is met. The condition is either a block height or an event in the outside world, such as a match result, that the registered nodes confirm by attestation. Triggers give time locks, delayed gifts and payouts on real-world outcomes without any contract code.

Creating a trigger

A CreateTrigger transaction (type 15) states a recipient, an amount and a condition. Triggers carry ZBC only. There are two kinds of condition:

• a height trigger names a block height, which must be in the future. A block comes every 15 seconds, so a height works like a date: one day ahead is 5,760 blocks;
• an event trigger names an event id, and fires when the registered nodes resolve that event; it stays pending until then or until it is cancelled. It also carries a fire height, which is not used.

The amount leaves the creator's balance at once and is locked. Until the trigger fires, the creator can take the money back with CancelTrigger (type 16). A trigger pays once: it runs no script, and it does not repeat.

Attestations: how events resolve

A blockchain cannot read the outside world by itself: if every node fetched a web page, they could see different answers and disagree. ZooBC uses attestations instead.

• A registered node sends an AttestEvent (type 17) carrying an event id and a value, each of at most 4,096 bytes.
• Each node has one vote per event: a newer attestation replaces its older one. Only attestations from registered nodes count.
• At the end of every block, the chain counts the attestations of each unresolved event. When two thirds of the active registry attest exactly the same value (8 of 11 seats, for example), that value becomes the event's result, for good.
• In that same block, every pending trigger that names the event pays its recipient.

An attestation is a fee-free duty: it declares a fee of exactly 0 and comes from the node's own account (see fees). No registry-wide decision resolves while the registry is below its floor of max(3, min_registry_size) seats and distinct owners, which is 7 on mainnet (see two-thirds rules).

Reserved event ids

The same attestations carry other network decisions, under reserved prefixes of the event id. Each is resolved by its own step, not by the trigger step:

With other features

• A trigger's payout is an incoming credit, so it passes through the recipient's split policy (see split and transact policies).
• A recipient's transact policy is checked only against the CreateTrigger itself; the release still reaches a recipient that opts out of payments later.
• In a transact policy, AttestEvent belongs to the Bridge category.

For payments that repeat, see scheduled transfers; for money that vests minute by minute, see liquid payments (streams).

See also

• The two-thirds rules
• The bridge and wrapped coins
• The node registry and its seats
• Escrow