Séquestre
Un séquestre est un paiement conservé par la chaîne elle-même jusqu’à ce qu’un tiers, l’approbateur, décide s’il aboutit. Aucune entreprise ne garde l’argent et aucun code de contrat n’intervient : un séquestre est un SendZBC ou un TransferToken ordinaire avec une partie supplémentaire dans son enveloppe, et les règles fixes de la chaîne le règlent. Il convient aux livraisons, aux missions en freelance ou à toute affaire dans laquelle le payeur veut un arbitre.
Créer un séquestre
La partie séquestre de la transaction désigne :
- l’approbateur, l’adresse qui jugera l’affaire ;
- une commission pour l’approbateur ;
- une échéance absolue, en secondes Unix, postérieure à l’horodatage de la transaction ;
- une instruction pour l’approbateur, comme « libérer à la livraison », d’au plus 128 000 octets et sans octet nul.
Seuls SendZBC et TransferToken peuvent porter une partie séquestre. Lorsqu’un bloc inclut la transaction, l’expéditeur paie le montant, les frais, la commission et le loyer du séquestre, et la chaîne conserve le montant et la commission. Dans un séquestre de jetons, le montant est en jetons, tandis que les frais, la commission et le loyer sont payés en ZBC.
Quatre issues
| Issue | Comment elle survient | Le montant va à | La commission va à |
|---|---|---|---|
| Approbation | l’approbateur envoie ApprovalEscrow | le destinataire | l’approbateur |
| Rejet | l’approbateur envoie ApprovalEscrow | l’expéditeur | l’approbateur |
| Refus | le destinataire envoie DeclineEscrowRequest | l’expéditeur | l’expéditeur |
| Échéance dépassée | le premier bloc après l’échéance, de lui-même | l’expéditeur | l’expéditeur |
L’approbateur touche sa commission, qu’il approuve ou qu’il rejette, car juger l’affaire était son travail dans les deux cas. Si le destinataire refuse, ou si personne n’agit à temps, l’expéditeur récupère les deux parties.
Un ApprovalEscrow a un corps de 36 octets : la valeur d’approbation et le hachage de la transaction sous séquestre. Seul l’approbateur désigné peut l’envoyer. Chaque séquestre se règle une seule fois, et une seconde approbation d’un séquestre déjà réglé est une opération nulle payante : elle paie ses frais et ne fait rien d’autre. L’expéditeur ne peut pas reprendre le paiement à volonté : seules ces quatre issues mettent fin à un séquestre. L’échéance est vérifiée d’après l’horodatage du bloc précédent (voir l’expiration et les horodatages).
La chaîne enregistre l’état de chaque séquestre sous la forme 0 en attente, 1 approuvé, 2 rejeté, 3 expiré ou 4 refusé.
Le loyer du séquestre
Un séquestre occupe l’état de la chaîne jusqu’à son règlement : il paie donc un loyer en plus des frais :
escrow rent = storage price of the escrow part's bytes × lock duration in blocks ÷ billing periodLe loyer est débité à la création du séquestre, va au fonds de longévité (voir les fonds) et n’est jamais remboursé, quelle que soit l’issue. GET /api/v1/blockchain/estimate-fee l’indique avant que vous signiez.
Une échéance située au-delà du moment où la transaction serait élaguée est refusée, sauf si le dépôt de survie de la transaction paie pour la conserver aussi longtemps (voir la longévité).
Les demandes de séquestre : le bénéficiaire commence
Parfois, c’est le bénéficiaire qui veut fixer les conditions. Avec une EscrowRequest, il publie le payeur, le montant, l’approbateur, la commission, l’échéance absolue, l’instruction et une fenêtre de financement en blocs. Le payeur peut alors soit la financer, avec un SendZBC sous séquestre dont les conditions correspondent exactement, soit la refuser avec une DeclineEscrowRequest. Une transaction de financement dont les conditions diffèrent est une opération nulle payante.
Un séquestre à plusieurs parties porte soit la cosignature du destinataire, soit l’identifiant d’une telle demande.