Je lisais Newton avec la même question que j’ai d’habitude pour les outils de coffre-fort.
Pas ce qu’ils peuvent faire.
Quelle part de l’ancien workflow gardent-ils ?
C’est là que VaultKit a commencé à me sembler différent.
La documentation décrit un SDK TypeScript et des contrats Solidity complémentaires, mais ce qui m’est resté en tête est plus petit que cela. Un curateur peut continuer à utiliser le flux de coffre-fort qu’il connaît déjà, tandis que chaque action est enveloppée dans une copie de Shield et envoyée via une attestation d’une politique Newton avant que le coffre-fort ne reçoive l’appel.
C’est un type de conception très spécifique.
Ce n’est pas une tentative de rendre la gestion des coffres-forts “nouvelle” juste pour le plaisir. L’objectif est de la rendre plus difficile à faire mal, sans forcer les équipes à reconstruire toute leur stack.
Je pense que c’est la vraie tension ici.
Dans les coffres DeFi, surtout quand des capitaux institutionnels sont impliqués, le problème n’est rarement uniquement la règle sur le papier. Le point le plus difficile est de s’assurer que la règle est réellement appliquée à chaque fois que le coffre-fort bouge. Newton essaie de faire passer la promesse du curateur directement dans le chemin d’exécution.
C’est pourquoi le workflow compte autant.
Le système utilise des clones déterministes par curateur via ShieldFactory, et Newton affirme que la couche de politique est active en beta sur le réseau principal. Donc ce n’est pas juste une belle idée qui reste dans un billet de blog. C’est un workflow construit autour d’une barrière placée avant que le coffre-fort n’agisse.
Mais il reste tout de même un compromis.
La réduction des frictions est une bonne chose seulement si les gestionnaires font suffisamment confiance au chemin d’attestation pour l’utiliser. Si le workflow semble lourd, ou si la barrière ressemble à un surcoût supplémentaire, les gens resteront avec tout ce qu’ils connaissaient déjà.
C’est la partie que je surveillerais.
Pas de savoir si la conformité des coffres-forts sonne bien.
Si VaultKit rend la conformité plus agréable, comme une amélioration du workflow, plutôt que comme une taxe.
C’est la façon la plus claire pour moi de lire Newton ici. La question n’est pas de savoir si les gestionnaires de coffres-forts devraient avoir des règles. La question est de savoir si ces règles peuvent vivre dans le même flux qu’ils utilisent déjà, sans transformer chaque mouvement en un nouveau processus pour s’en sortir.
@NewtonProtocol #newt $NEWT
Pas ce qu’ils peuvent faire.
Quelle part de l’ancien workflow gardent-ils ?
C’est là que VaultKit a commencé à me sembler différent.
La documentation décrit un SDK TypeScript et des contrats Solidity complémentaires, mais ce qui m’est resté en tête est plus petit que cela. Un curateur peut continuer à utiliser le flux de coffre-fort qu’il connaît déjà, tandis que chaque action est enveloppée dans une copie de Shield et envoyée via une attestation d’une politique Newton avant que le coffre-fort ne reçoive l’appel.
C’est un type de conception très spécifique.
Ce n’est pas une tentative de rendre la gestion des coffres-forts “nouvelle” juste pour le plaisir. L’objectif est de la rendre plus difficile à faire mal, sans forcer les équipes à reconstruire toute leur stack.
Je pense que c’est la vraie tension ici.
Dans les coffres DeFi, surtout quand des capitaux institutionnels sont impliqués, le problème n’est rarement uniquement la règle sur le papier. Le point le plus difficile est de s’assurer que la règle est réellement appliquée à chaque fois que le coffre-fort bouge. Newton essaie de faire passer la promesse du curateur directement dans le chemin d’exécution.
C’est pourquoi le workflow compte autant.
Le système utilise des clones déterministes par curateur via ShieldFactory, et Newton affirme que la couche de politique est active en beta sur le réseau principal. Donc ce n’est pas juste une belle idée qui reste dans un billet de blog. C’est un workflow construit autour d’une barrière placée avant que le coffre-fort n’agisse.
Mais il reste tout de même un compromis.
La réduction des frictions est une bonne chose seulement si les gestionnaires font suffisamment confiance au chemin d’attestation pour l’utiliser. Si le workflow semble lourd, ou si la barrière ressemble à un surcoût supplémentaire, les gens resteront avec tout ce qu’ils connaissaient déjà.
C’est la partie que je surveillerais.
Pas de savoir si la conformité des coffres-forts sonne bien.
Si VaultKit rend la conformité plus agréable, comme une amélioration du workflow, plutôt que comme une taxe.
C’est la façon la plus claire pour moi de lire Newton ici. La question n’est pas de savoir si les gestionnaires de coffres-forts devraient avoir des règles. La question est de savoir si ces règles peuvent vivre dans le même flux qu’ils utilisent déjà, sans transformer chaque mouvement en un nouveau processus pour s’en sortir.
@NewtonProtocol #newt $NEWT