Escrow

An escrow is a payment held by the chain itself until a third party, the approver, decides whether it goes through. No company keeps the money and no contract code is involved: an escrow is an ordinary SendZBC or TransferToken with an extra part in its envelope, and the chain's fixed rules settle it. It suits deliveries, freelance work, or any deal in which the payer wants a referee.

Making an escrow

The escrow part of the transaction names:

• the approver, the address that will judge the deal;
• a commission for the approver;
• an absolute deadline, in Unix seconds, later than the transaction's timestamp;
• an instruction for the approver, such as "release on delivery", of at most 128,000 bytes with no zero byte.

Only SendZBC and TransferToken may carry an escrow part. When a block includes the transaction, the sender pays the amount, the fee, the commission and the escrow rent, and the chain holds the amount and the commission. In a token escrow the amount is in the token, while the fee, the commission and the rent are paid in ZBC.

Four endings

The approver earns its commission whether it approves or rejects, because judging the deal was its job either way. If the recipient declines, or if nobody acts in time, the sender gets both parts back.

An ApprovalEscrow has a 36-byte body: the approval value and the hash of the escrowed transaction. Only the named approver can send it. Each escrow settles once, and a second approval of a settled escrow is a paid no-op: it pays its fee and does nothing else. The sender cannot pull the payment back at will: only these four endings close an escrow. The deadline is checked against the previous block's timestamp (see expiry and timestamps).

The chain records each escrow's status as 0 pending, 1 approved, 2 rejected, 3 expired or 4 declined.

Escrow rent

An escrow occupies the chain's state until it settles, so it pays rent on top of the fee:

escrow rent = storage price of the escrow part's bytes × lock duration in blocks ÷ billing period

The rent is debited when the escrow is created, goes to the longevity pool (see pools) and is never refunded, whatever the ending. GET /api/v1/blockchain/estimate-fee reports it before you sign.

A deadline that lies beyond the point where the transaction would be pruned is refused, unless the transaction's survival deposit pays to keep it stored that long (see paying to keep data (longevity)).

Escrow requests: the payee goes first

Sometimes the payee wants to set the terms. With an EscrowRequest, the payee publishes the payer, the amount, the approver, the commission, the absolute deadline, the instruction and a funding window in blocks. The payer then either funds it, with an escrowed SendZBC whose terms match exactly, or declines it with a DeclineEscrowRequest. A funding transaction whose terms differ is a paid no-op.

A multi-party escrow carries either the recipient's co-signature or the id of such a request.

See also

• Transactions
• Multisignature
• Issuing a token
• The pools
• Project ideas