Quelque chose à propos de l’abstraction de mise de Dusk m’a fait arrêter de penser à la mise comme à une « fonctionnalité ».
J’ai commencé à regarder les callbacks à la place.
Ça ressemble à un petit détail technique, mais les callbacks me disent généralement où un protocole s’attend à ce que d’autres logiciels puissent s’intégrer.
Un contrat dépose des fonds.
Il envoie la mise via le contrat de transfert.
La mise devient active autour d’une frontière d’époque.
Plus tard, les récompenses ou les fonds désengagés reviennent via des callbacks du contrat.
Ce n’est donc pas seulement de la mise.
C’est un cycle de vie.
Et nous avons déjà vu ce schéma ailleurs dans la crypto.
ERC-4626 a permis de transformer les coffres en quelque chose que les applications peuvent intégrer via une interface commune.
Puis ERC-7540 a fait évoluer l’idée pour les cas où les dépôts et retraits ne sont pas instantanés, car certains systèmes financiers ont naturellement des périodes d’attente et un règlement asynchrone.
Dusk gère un autre type de processus asynchrone, mais l’intuition de conception me paraît familière :
rendre le cycle de vie programmable, pas seulement l’actif.
Cela change ce que peut réellement représenter un contrat de staking.
Il n’a pas forcément besoin d’être « un pool ».
Il peut encoder des règles autour de qui participe, du moment où le capital bouge, de la façon dont les récompenses sont acheminées, ou de ce qui se passe après un désengagement.
Et c’est la partie que je trouve plus intéressante que le récit habituel du staking.
Le protocole possède toujours les règles de sécurité.
Mais le contrat peut posséder le comportement autour de la position.
Pour moi, c’est une abstraction bien plus intéressante que de rendre simplement le staking plus facile.
On commence à faire se comporter la mise moins comme un bouton qu’on appuie…
et davantage comme une position programmable dotée d’un cycle de vie.
C’est là que je commencerais à chercher la prochaine vague de primitives DUSK.
#dusk $DUSK @Dusk
$TMX $BMT
J’ai commencé à regarder les callbacks à la place.
Ça ressemble à un petit détail technique, mais les callbacks me disent généralement où un protocole s’attend à ce que d’autres logiciels puissent s’intégrer.
Un contrat dépose des fonds.
Il envoie la mise via le contrat de transfert.
La mise devient active autour d’une frontière d’époque.
Plus tard, les récompenses ou les fonds désengagés reviennent via des callbacks du contrat.
Ce n’est donc pas seulement de la mise.
C’est un cycle de vie.
Et nous avons déjà vu ce schéma ailleurs dans la crypto.
ERC-4626 a permis de transformer les coffres en quelque chose que les applications peuvent intégrer via une interface commune.
Puis ERC-7540 a fait évoluer l’idée pour les cas où les dépôts et retraits ne sont pas instantanés, car certains systèmes financiers ont naturellement des périodes d’attente et un règlement asynchrone.
Dusk gère un autre type de processus asynchrone, mais l’intuition de conception me paraît familière :
rendre le cycle de vie programmable, pas seulement l’actif.
Cela change ce que peut réellement représenter un contrat de staking.
Il n’a pas forcément besoin d’être « un pool ».
Il peut encoder des règles autour de qui participe, du moment où le capital bouge, de la façon dont les récompenses sont acheminées, ou de ce qui se passe après un désengagement.
Et c’est la partie que je trouve plus intéressante que le récit habituel du staking.
Le protocole possède toujours les règles de sécurité.
Mais le contrat peut posséder le comportement autour de la position.
Pour moi, c’est une abstraction bien plus intéressante que de rendre simplement le staking plus facile.
On commence à faire se comporter la mise moins comme un bouton qu’on appuie…
et davantage comme une position programmable dotée d’un cycle de vie.
C’est là que je commencerais à chercher la prochaine vague de primitives DUSK.
#dusk $DUSK @Dusk
$TMX $BMT
Bullish ☝️
100%
Bearish👇
0%
4 Votes • Vote fermé