Politiques de répartition et de transaction
Deux réglages de compte déterminent ce qui parvient à un compte. Une politique de répartition reverse des parts fixes de chaque crédit entrant, en ZBC ou en n’importe quel jeton, à dix autres adresses au plus : redevances, revenus partagés entre partenaires ou épargne automatique. Une politique de transaction refuse des catégories entières de transactions dans les deux sens, de sorte que personne ne puisse, par exemple, envoyer au compte des jetons indésirables. Chacune se définit par une seule transaction et reste en place jusqu’à ce qu’on la modifie.
Politique de répartition
Une transaction SetSplitPolicy (type 54) liste jusqu’à 10 destinataires, chacun avec une part en points de base (100 points de base font 1 %) :
- chaque part vaut au moins 1 point de base, et toutes les parts réunies font au plus 10 000 (100 %) ;
- aucun destinataire ne peut figurer deux fois, et le compte ne peut pas se désigner lui-même ;
- chaque destinataire doit pouvoir détenir des fonds.
Un corps 00 efface la politique.
Ce qui est réparti
La politique s’applique à chaque crédit entrant, en ZBC et en jetons : paiements, libérations de séquestre, déclencheurs, versements de flux, paiements en mode acquisition, transferts de jetons, exécutions d’ordres, versements d’applis et récompenses. Elle ne s’applique pas aux remboursements de l’argent propre du compte (comme un séquestre rendu à son expéditeur), aux paiements programmés en mode prélèvement (pull), ni aux frappes du pont.
Chaque part vaut floor(amount × basis points ÷ 10,000), et ce qui n’est attribué à personne, arrondis compris, reste sur le compte. Les parts ne se propagent pas en cascade : la propre politique de répartition d’un destinataire n’est pas appliquée à ce qu’il reçoit par une répartition, de sorte que l’argent ne peut pas tourner en boucle. Un destinataire dont la politique de transaction refuse les paiements est ignoré, et sa part reste sur le compte.
Dans un groupe de comptes, seul le contrôleur définit la politique, et la politique du groupe s’applique à l’argent envoyé à n’importe quel membre. Une adresse qui a une politique de répartition ne peut pas rejoindre un groupe.
Politique de transaction
Une transaction SetTransactPolicy (type 50) enregistre sur le compte un masque de 2 octets. Chaque bit refuse une catégorie de transactions dans les deux sens : le compte ne les enverra ni ne les recevra.
| Bit | Catégorie |
|---|---|
| 0 | Paiements |
| 1 | Applis |
| 2 | Jetons |
| 3 | Bourse d’échange |
| 4 | Stockage de données |
| 5 | Séquestre et multisignature |
| 6 | Infrastructure des nœuds |
| 7 | Pont (AttestEvent) |
| 8 | Gouvernance |
Quelques types ne sont jamais refusés : Empty, SetTransactPolicy, SetSplitPolicy, les types de longévité et les types de groupe de comptes.
Comment fonctionne le refus
Un nœud refuse une transaction qu’une politique interdit dès qu’elle est soumise. Si un bloc en contient une tout de même, elle est renvoyée : l’expéditeur paie les frais et rien ne bouge. Seul le destinataire nommé dans l’enveloppe de la transaction est vérifié, au moment où la transaction s’exécute. Les paiements que la chaîne effectue plus tard au titre d’une transaction antérieure, comme les paiements programmés, les libérations par déclencheur et les versements de flux, parviennent quand même à un destinataire qui s’est exclu.
Une politique de transaction n’est pas un réglage de frais, puisque les frais découlent du plancher de chaque transaction, et elle ne choisit pas les producteurs de blocs, que la chaîne tire au sort. Pour des limites de dépense sur les membres d’un compte partagé, voir les groupes de comptes.