EthanValeX
1.8k Publications
EthanValeX
Sharing market insights, real-world DCA & futures strategies.
No hype. No FOMO. Just discipline.
Follow me.
Détenteur pour U
Trade régulièrement
5.9 an(s)
122 Suivis
506 Abonnés
1.5K+ J’aime
Publications
Tous
Citations
Vidéos
Voir la traduction
Last night, I was reading Grvt’s explanation of Validium when one uncomfortable detail made me stop.
User funds may be difficult to steal, yet they can still become unavailable.
At first, those two outcomes sounded contradictory.
Grvt uses zero-knowledge proofs to prove that a state transition is valid without publishing the full transaction data to Ethereum. The network can verify that balances and positions were updated according to the rules, while traders avoid exposing their entire activity on a public ledger.
For an exchange, that privacy has real value.
Public positions can reveal strategy, make large traders easier to track, and create opportunities for front-running or copy trading. Grvt’s private Validium reduces that information leakage without asking Ethereum to process every piece of trading data.
But the proof only answers one question:
Was the state transition valid?
It does not answer another:
Will the data behind that transition remain available when users need it?
Grvt’s operator keeps transaction data off-chain. Ethereum receives proof that the new state is correct, but it does not receive enough data to reconstruct the full trading history itself.
That creates a very specific boundary.
If the operator submits an invalid transition, the proof should fail. But if the operator stops serving data, the blockchain may still know that the latest state is valid while users lose the information needed to reconstruct their accounts or exit normally.
So Grvt does not ask users to trust the operator with the correctness of every trade.
It asks them to trust the operator with continued access to the history behind those trades.
That is the price hidden inside private execution: less information exposed to the market, but greater dependence on whoever preserves the missing data.
Can an exchange call itself self-custodial if users own the funds, but the operator still controls the data required to leave?
@grvt_io #grvt
User funds may be difficult to steal, yet they can still become unavailable.
At first, those two outcomes sounded contradictory.
Grvt uses zero-knowledge proofs to prove that a state transition is valid without publishing the full transaction data to Ethereum. The network can verify that balances and positions were updated according to the rules, while traders avoid exposing their entire activity on a public ledger.
For an exchange, that privacy has real value.
Public positions can reveal strategy, make large traders easier to track, and create opportunities for front-running or copy trading. Grvt’s private Validium reduces that information leakage without asking Ethereum to process every piece of trading data.
But the proof only answers one question:
Was the state transition valid?
It does not answer another:
Will the data behind that transition remain available when users need it?
Grvt’s operator keeps transaction data off-chain. Ethereum receives proof that the new state is correct, but it does not receive enough data to reconstruct the full trading history itself.
That creates a very specific boundary.
If the operator submits an invalid transition, the proof should fail. But if the operator stops serving data, the blockchain may still know that the latest state is valid while users lose the information needed to reconstruct their accounts or exit normally.
So Grvt does not ask users to trust the operator with the correctness of every trade.
It asks them to trust the operator with continued access to the history behind those trades.
That is the price hidden inside private execution: less information exposed to the market, but greater dependence on whoever preserves the missing data.
Can an exchange call itself self-custodial if users own the funds, but the operator still controls the data required to leave?
@grvt_io #grvt
Je pensais autrefois qu’un oubli de validation était la partie la plus effrayante.
Les documents de Newton m’ont fait penser que le cas le plus effrayant est lorsque la vérification existe, mais se trouve au mauvais endroit.
Une ligne dans le guide d’intégration du Smart Contract m’a fait m’arrêter :
Vérifiez avant l’exécution.
Au début, cela ressemble à une hygiène basique en Solidity.
Vérifier d’abord.
Puis exécuter la logique.
Rien de bien compliqué.
Mais, dans le design de @NewtonProtocol , l’ordre change tout.
Un contrat peut appeler _validateAttestation(). Il peut vérifier l’intention, la politique, l’expiration, le chainId et l’appelant. Sur le papier, il peut sembler que l’application utilise Newton correctement.
Mais si la logique métier s’est déjà exécutée avant cette validation, la politique ne tient plus le rôle de garde à l’entrée.
Elle est placée après la conséquence.
Les fonds peuvent avoir bougé.
Un coffre peut avoir été retiré.
Un token peut avoir été émis.
Un contrat externe a peut-être déjà été appelé.
À ce moment-là, le même contrôle Newton ne bloque plus l’exécution.
Il ne fait que décrire quelque chose qui a peut-être déjà eu lieu.
C’est à cette partie que je reviens sans cesse.
La question ne porte pas seulement sur le fait qu’un contrat appelle Newton.
La question est de savoir où cet appel se situe dans le chemin d’exécution.
Je vois cela comme une Discipline d’Ordre d’Exécution.
L’autorisation ne doit pas seulement exister dans le flux. Elle doit se trouver avant que toute modification significative de l’état ne commence.
Si la validation intervient avant la logique métier, la politique agit comme une barrière.
Si la validation intervient après la logique métier, la politique devient un reçu.
Le point difficile, c’est que les contrats complexes peuvent brouiller le “avant” et le “après”. Les appels internes, les appels externes, les hooks, les callbacks et la logique de coffre peuvent tous créer des conséquences plus tôt que prévu.
Donc la validation ne peut pas simplement apparaître avant une seule ligne de code visible.
Elle doit protéger l’ensemble du chemin d’exécution.
Peut-être que l’autorisation on-chain ne concerne pas seulement l’écriture de règles plus solides.
Il s’agit de s’assurer qu’aucune action ne commence avant que ces règles ne soient vérifiées.
$NEWT $LAB #Newt
Les documents de Newton m’ont fait penser que le cas le plus effrayant est lorsque la vérification existe, mais se trouve au mauvais endroit.
Une ligne dans le guide d’intégration du Smart Contract m’a fait m’arrêter :
Vérifiez avant l’exécution.
Au début, cela ressemble à une hygiène basique en Solidity.
Vérifier d’abord.
Puis exécuter la logique.
Rien de bien compliqué.
Mais, dans le design de @NewtonProtocol , l’ordre change tout.
Un contrat peut appeler _validateAttestation(). Il peut vérifier l’intention, la politique, l’expiration, le chainId et l’appelant. Sur le papier, il peut sembler que l’application utilise Newton correctement.
Mais si la logique métier s’est déjà exécutée avant cette validation, la politique ne tient plus le rôle de garde à l’entrée.
Elle est placée après la conséquence.
Les fonds peuvent avoir bougé.
Un coffre peut avoir été retiré.
Un token peut avoir été émis.
Un contrat externe a peut-être déjà été appelé.
À ce moment-là, le même contrôle Newton ne bloque plus l’exécution.
Il ne fait que décrire quelque chose qui a peut-être déjà eu lieu.
C’est à cette partie que je reviens sans cesse.
La question ne porte pas seulement sur le fait qu’un contrat appelle Newton.
La question est de savoir où cet appel se situe dans le chemin d’exécution.
Je vois cela comme une Discipline d’Ordre d’Exécution.
L’autorisation ne doit pas seulement exister dans le flux. Elle doit se trouver avant que toute modification significative de l’état ne commence.
Si la validation intervient avant la logique métier, la politique agit comme une barrière.
Si la validation intervient après la logique métier, la politique devient un reçu.
Le point difficile, c’est que les contrats complexes peuvent brouiller le “avant” et le “après”. Les appels internes, les appels externes, les hooks, les callbacks et la logique de coffre peuvent tous créer des conséquences plus tôt que prévu.
Donc la validation ne peut pas simplement apparaître avant une seule ligne de code visible.
Elle doit protéger l’ensemble du chemin d’exécution.
Peut-être que l’autorisation on-chain ne concerne pas seulement l’écriture de règles plus solides.
Il s’agit de s’assurer qu’aucune action ne commence avant que ces règles ne soient vérifiées.
$NEWT $LAB #Newt
La conformité inter-chaînes casse dès l’instant où « vérifié » devient « quelqu’un m’a dit ».
C’est, je pense, le problème que @NewtonProtocol essaie de réduire.
Sur le papier, déplacer une autorisation d’une chaîne à l’autre paraît simple.
Une chaîne vérifie la politique.
Une autre chaîne reçoit le résultat.
La transaction se poursuit.
Mais le règlement ne devrait pas fonctionner comme une capture d’écran transmise.
Si une valeur se déplace sur la chaîne de destination, cette chaîne ne devrait pas seulement recevoir un message indiquant que la politique a été approuvée. Elle devrait aussi pouvoir vérifier elle-même l’approbation avant l’exécution.
C’est là que le chemin de certificat BN254 de Newton devient plus intéressant que ce que son nom laisse penser.
L’enjeu n’est pas le nom de la courbe.
L’enjeu, c’est qu’une approbation inter-chaînes doit emporter une forme que le vérificateur de destination puisse vérifier onchain : la signature agrégée, l’instantané de l’opérateur et le point de référence de la chaîne source.
Sans ce contexte, une preuve peut traverser les chaînes tout en perdant la raison pour laquelle elle était fiable à l’origine.
Cela change mon point de vue.
La conformité inter-chaînes ne consiste pas uniquement à faire circuler des règles entre réseaux.
Il s’agit de s’assurer que la chaîne où le règlement a lieu conserve toujours le droit de dire non.
Cette limite compte car, à mesure que les stablecoins, les RWA, les positions dans des vaults et les transactions d’agents deviennent plus multichaînes, un contrôle de politique sur une chaîne ne devrait pas s’affaiblir simplement parce que l’actif apparaît ailleurs.
Le compromis, c’est la complexité.
L’état du vérificateur doit rester à jour. Les instantanés de l’opérateur doivent rester pertinents. Les certificats doivent être vérifiés avant l’exécution, et non traités comme de la simple paperasse une fois les faits accomplis.
Mais sans cela, la conformité inter-chaînes devient un pont de confiance, pas une couche de vérification.
Newton rend-il l’autorisation inter-chaînes portable sans transformer la chaîne de destination en simple réceptrice aveugle ?
#Newt $NEWT $LAB
C’est, je pense, le problème que @NewtonProtocol essaie de réduire.
Sur le papier, déplacer une autorisation d’une chaîne à l’autre paraît simple.
Une chaîne vérifie la politique.
Une autre chaîne reçoit le résultat.
La transaction se poursuit.
Mais le règlement ne devrait pas fonctionner comme une capture d’écran transmise.
Si une valeur se déplace sur la chaîne de destination, cette chaîne ne devrait pas seulement recevoir un message indiquant que la politique a été approuvée. Elle devrait aussi pouvoir vérifier elle-même l’approbation avant l’exécution.
C’est là que le chemin de certificat BN254 de Newton devient plus intéressant que ce que son nom laisse penser.
L’enjeu n’est pas le nom de la courbe.
L’enjeu, c’est qu’une approbation inter-chaînes doit emporter une forme que le vérificateur de destination puisse vérifier onchain : la signature agrégée, l’instantané de l’opérateur et le point de référence de la chaîne source.
Sans ce contexte, une preuve peut traverser les chaînes tout en perdant la raison pour laquelle elle était fiable à l’origine.
Cela change mon point de vue.
La conformité inter-chaînes ne consiste pas uniquement à faire circuler des règles entre réseaux.
Il s’agit de s’assurer que la chaîne où le règlement a lieu conserve toujours le droit de dire non.
Cette limite compte car, à mesure que les stablecoins, les RWA, les positions dans des vaults et les transactions d’agents deviennent plus multichaînes, un contrôle de politique sur une chaîne ne devrait pas s’affaiblir simplement parce que l’actif apparaît ailleurs.
Le compromis, c’est la complexité.
L’état du vérificateur doit rester à jour. Les instantanés de l’opérateur doivent rester pertinents. Les certificats doivent être vérifiés avant l’exécution, et non traités comme de la simple paperasse une fois les faits accomplis.
Mais sans cela, la conformité inter-chaînes devient un pont de confiance, pas une couche de vérification.
Newton rend-il l’autorisation inter-chaînes portable sans transformer la chaîne de destination en simple réceptrice aveugle ?
#Newt $NEWT $LAB
Je reviens sans cesse à un petit détail dans la conception de l’Oracle de données de Newton.
Les fichiers de schéma.
Au début, wasm_args_schema.json et params_schema.json semblaient n’être qu’une documentation pour développeurs. Un moyen d’indiquer aux appelants quels champs envoyer, quels types utiliser et comment éviter les requêtes mal formées.
C’est utile, mais pas très profond.
Mais plus je l’étudiais, plus je me suis rendu compte que le schéma fait quelque chose de plus important à l’intérieur de @NewtonProtocol .
Il définit la forme du monde sur lequel une politique est autorisée à raisonner.
Une politique Rego n’évalue pas la réalité directement. Elle évalue des données structurées. L’Oracle de données reçoit wasm_args, traite un contexte externe et renvoie du JSON dans data.wasm. La configuration de PolicyClient apparaît comme data.params.
Si ces formes sont souples, la politique peut rester correcte en tant que code, mais fragile en tant qu’exécution.
Si un oracle s’attend à vaultAddress mais reçoit vault_address, la politique peut encore s’exécuter. Mais elle ne raisonne plus sur l’objet tel que le concepteur l’avait prévu.
C’est là que la Discipline de Schéma compte.
Newton ne demande pas seulement aux concepteurs d’écrire des règles. Il leur demande de déclarer le contrat de données dont ces règles dépendent avant même le début de l’évaluation.
Cela change la frontière des responsabilités.
L’appelant ne peut pas simplement envoyer n’importe quel blob d’entrée pratique. L’Oracle ne peut pas supposer silencieusement que les champs existent dans la forme qui lui convient. La politique ne peut pas prétendre que sa logique est indépendante de la forme des données qui l’alimentent.
Le schéma devient l’accord entre l’appelant, l’oracle et la politique.
Il ne décide pas si une transaction doit être autorisée. Mais il décide si le système regarde même le bon type d’objet avant que l’autorisation commence.
Pourtant, les schémas ont des limites.
Ils peuvent valider la structure, mais pas la vérité. Un champ peut être bien formé tout en étant périmé, manipulé ou économiquement trompeur.
C’est la partie à laquelle je reviens encore et encore.
Chez Newton, la sécurité de la politique ne commence pas par la règle.
Elle commence par la forme des données que la règle est autorisée à croire.
$NEWT $LAB #Newt
Les fichiers de schéma.
Au début, wasm_args_schema.json et params_schema.json semblaient n’être qu’une documentation pour développeurs. Un moyen d’indiquer aux appelants quels champs envoyer, quels types utiliser et comment éviter les requêtes mal formées.
C’est utile, mais pas très profond.
Mais plus je l’étudiais, plus je me suis rendu compte que le schéma fait quelque chose de plus important à l’intérieur de @NewtonProtocol .
Il définit la forme du monde sur lequel une politique est autorisée à raisonner.
Une politique Rego n’évalue pas la réalité directement. Elle évalue des données structurées. L’Oracle de données reçoit wasm_args, traite un contexte externe et renvoie du JSON dans data.wasm. La configuration de PolicyClient apparaît comme data.params.
Si ces formes sont souples, la politique peut rester correcte en tant que code, mais fragile en tant qu’exécution.
Si un oracle s’attend à vaultAddress mais reçoit vault_address, la politique peut encore s’exécuter. Mais elle ne raisonne plus sur l’objet tel que le concepteur l’avait prévu.
C’est là que la Discipline de Schéma compte.
Newton ne demande pas seulement aux concepteurs d’écrire des règles. Il leur demande de déclarer le contrat de données dont ces règles dépendent avant même le début de l’évaluation.
Cela change la frontière des responsabilités.
L’appelant ne peut pas simplement envoyer n’importe quel blob d’entrée pratique. L’Oracle ne peut pas supposer silencieusement que les champs existent dans la forme qui lui convient. La politique ne peut pas prétendre que sa logique est indépendante de la forme des données qui l’alimentent.
Le schéma devient l’accord entre l’appelant, l’oracle et la politique.
Il ne décide pas si une transaction doit être autorisée. Mais il décide si le système regarde même le bon type d’objet avant que l’autorisation commence.
Pourtant, les schémas ont des limites.
Ils peuvent valider la structure, mais pas la vérité. Un champ peut être bien formé tout en étant périmé, manipulé ou économiquement trompeur.
C’est la partie à laquelle je reviens encore et encore.
Chez Newton, la sécurité de la politique ne commence pas par la règle.
Elle commence par la forme des données que la règle est autorisée à croire.
$NEWT $LAB #Newt
Le détail qui m’a fait repenser le modèle d’autorisation de Newton n’était pas la signature elle-même.
C’était cette limite :
intent.from == msg.sender
Au premier abord, cela ressemble à une simple vérification de contrat intelligent.
Bien sûr, l’appelant doit correspondre à l’adresse indiquée dans l’intention. Rien d’étonnant là.
Mais plus j’y pensais, plus cette petite vérification a commencé à ressembler au cœur du problème de rejeu.
Une signature prouve seulement que quelqu’un a approuvé quelque chose à un moment donné.
Elle ne prouve pas automatiquement que cette approbation revient via le bon appelant, sur la bonne chaîne, selon la bonne politique, avant l’expiration, et avant qu’elle n’ait déjà été utilisée.
C’est précisément là que la limite de validation de @NewtonProtocol compte.
Newton ne traite pas l’autorisation comme une permission lâche qui peut dériver après avoir été signée. L’intention porte du contexte : l’émetteur, le contrat cible, les calldata, la valeur, l’identifiant de chaîne (chainId) et la signature de la fonction. Le contrat valide ensuite que l’autorisation reste bien rattachée au chemin d’exécution pour lequel elle a été créée.
Cela change la façon dont je réfléchis à la protection contre le rejeu.
L’objectif n’est pas seulement de se demander si une approbation existait.
L’objectif est de réduire la durée de vie de cette approbation.
Elle ne peut pas se détacher de l’appelant. Elle ne peut pas migrer vers une autre chaîne. Elle ne peut pas survivre en dehors du contexte de politique qui l’a produite. Elle ne peut pas dépasser sa fenêtre d’expiration. Elle ne peut pas être utilisée deux fois.
La signature compte encore, mais la limite autour de la signature compte tout autant.
Cela ressemble à un détail d’implémentation mineur, mais c’est en réalité un choix de conception plus profond. Newton rend l’autorisation contextuelle plutôt que portable par défaut.
Une signature n’est pas une permission pour toujours.
C’est une permission à l’intérieur d’une frontière précise.
Et c’est peut-être la partie dont l’automatisation on-chain a le plus besoin : pas seulement des approbations plus solides, mais des approbations qui ne peuvent pas s’éloigner du contexte qui les a créées.
La protection contre le rejeu rend-elle l’autorisation plus sûre, ou nous rappelle-t-elle que toute approbation réutilisable est déjà une surface de risque ?
#Newt $NEWT $LAB
C’était cette limite :
intent.from == msg.sender
Au premier abord, cela ressemble à une simple vérification de contrat intelligent.
Bien sûr, l’appelant doit correspondre à l’adresse indiquée dans l’intention. Rien d’étonnant là.
Mais plus j’y pensais, plus cette petite vérification a commencé à ressembler au cœur du problème de rejeu.
Une signature prouve seulement que quelqu’un a approuvé quelque chose à un moment donné.
Elle ne prouve pas automatiquement que cette approbation revient via le bon appelant, sur la bonne chaîne, selon la bonne politique, avant l’expiration, et avant qu’elle n’ait déjà été utilisée.
C’est précisément là que la limite de validation de @NewtonProtocol compte.
Newton ne traite pas l’autorisation comme une permission lâche qui peut dériver après avoir été signée. L’intention porte du contexte : l’émetteur, le contrat cible, les calldata, la valeur, l’identifiant de chaîne (chainId) et la signature de la fonction. Le contrat valide ensuite que l’autorisation reste bien rattachée au chemin d’exécution pour lequel elle a été créée.
Cela change la façon dont je réfléchis à la protection contre le rejeu.
L’objectif n’est pas seulement de se demander si une approbation existait.
L’objectif est de réduire la durée de vie de cette approbation.
Elle ne peut pas se détacher de l’appelant. Elle ne peut pas migrer vers une autre chaîne. Elle ne peut pas survivre en dehors du contexte de politique qui l’a produite. Elle ne peut pas dépasser sa fenêtre d’expiration. Elle ne peut pas être utilisée deux fois.
La signature compte encore, mais la limite autour de la signature compte tout autant.
Cela ressemble à un détail d’implémentation mineur, mais c’est en réalité un choix de conception plus profond. Newton rend l’autorisation contextuelle plutôt que portable par défaut.
Une signature n’est pas une permission pour toujours.
C’est une permission à l’intérieur d’une frontière précise.
Et c’est peut-être la partie dont l’automatisation on-chain a le plus besoin : pas seulement des approbations plus solides, mais des approbations qui ne peuvent pas s’éloigner du contexte qui les a créées.
La protection contre le rejeu rend-elle l’autorisation plus sûre, ou nous rappelle-t-elle que toute approbation réutilisable est déjà une surface de risque ?
#Newt $NEWT $LAB
Un jeton RWA peut ressembler à une crypto-monnaie mème onchain.
C’est exactement ce qui me dérange.
Un portefeuille affiche un solde.
Un contrat expose transfer().
Un explorateur de blocs montre un actif ERC-20.
Mais je ne pense pas que les RWA puissent reprendre l’hypothèse des memecoins selon laquelle transfer doit être ouvert par défaut.
Avec des actifs du monde réel, la propriété n’est qu’une partie de l’histoire. La partie la plus difficile est de savoir si le détenteur est encore autorisé à transférer au moment où la transaction a lieu.
Cette condition peut changer.
Un justificatif peut expirer. Une juridiction peut devenir restreinte. Un fonds peut mettre à jour les règles des investisseurs. Une contrepartie peut devenir inéligible. Le jeton peut encore sembler transférable, tandis que l’autorisation qui le sous-tend est devenue obsolète.
C’est là que la conformité côté interface me paraît faible.
Une interface peut masquer le bouton de transfert. Mais si le contrat accepte encore transfer(), la restriction est purement esthétique. L’utilisateur peut passer par une autre interface ou appeler directement le contrat.
Ce n’est pas de l’application stricte.
C’est une hypothèse d’interface.
C’est pourquoi @NewtonProtocol correspond mieux au problème des RWA qu’un tableau de bord de conformité classique.
L’angle important de Newton n’est pas que des politiques puissent décrire des restrictions. C’est que l’évaluation de la politique peut se placer dans le chemin d’autorisation avant que l’actif ne bouge. La politique devient quelque chose sur quoi le smart contract peut s’appuyer.
Avant l’exécution, le contexte de politique actuel peut vérifier l’éligibilité, l’état du justificatif, la juridiction, les limites de transfert ou le risque lié à la contrepartie.
Ce qui m’a particulièrement frappé, c’est le problème d’éligibilité devenue obsolète.
Si les changements de règles ne sont pas vérifiés à proximité de l’exécution, une RWA peut sembler conforme alors que le chemin réel de transfert reste ouvert.
La partie que je n’ai pas encore totalement tranchée, c’est le compromis.
L’autorisation au niveau de la transaction rend-elle les RWA plus sûres, ou transforme-t-elle les actifs tokenisés en produits réglementés portant des habits ERC-20 ?
#Newt $LAB $NEWT
C’est exactement ce qui me dérange.
Un portefeuille affiche un solde.
Un contrat expose transfer().
Un explorateur de blocs montre un actif ERC-20.
Mais je ne pense pas que les RWA puissent reprendre l’hypothèse des memecoins selon laquelle transfer doit être ouvert par défaut.
Avec des actifs du monde réel, la propriété n’est qu’une partie de l’histoire. La partie la plus difficile est de savoir si le détenteur est encore autorisé à transférer au moment où la transaction a lieu.
Cette condition peut changer.
Un justificatif peut expirer. Une juridiction peut devenir restreinte. Un fonds peut mettre à jour les règles des investisseurs. Une contrepartie peut devenir inéligible. Le jeton peut encore sembler transférable, tandis que l’autorisation qui le sous-tend est devenue obsolète.
C’est là que la conformité côté interface me paraît faible.
Une interface peut masquer le bouton de transfert. Mais si le contrat accepte encore transfer(), la restriction est purement esthétique. L’utilisateur peut passer par une autre interface ou appeler directement le contrat.
Ce n’est pas de l’application stricte.
C’est une hypothèse d’interface.
C’est pourquoi @NewtonProtocol correspond mieux au problème des RWA qu’un tableau de bord de conformité classique.
L’angle important de Newton n’est pas que des politiques puissent décrire des restrictions. C’est que l’évaluation de la politique peut se placer dans le chemin d’autorisation avant que l’actif ne bouge. La politique devient quelque chose sur quoi le smart contract peut s’appuyer.
Avant l’exécution, le contexte de politique actuel peut vérifier l’éligibilité, l’état du justificatif, la juridiction, les limites de transfert ou le risque lié à la contrepartie.
Ce qui m’a particulièrement frappé, c’est le problème d’éligibilité devenue obsolète.
Si les changements de règles ne sont pas vérifiés à proximité de l’exécution, une RWA peut sembler conforme alors que le chemin réel de transfert reste ouvert.
La partie que je n’ai pas encore totalement tranchée, c’est le compromis.
L’autorisation au niveau de la transaction rend-elle les RWA plus sûres, ou transforme-t-elle les actifs tokenisés en produits réglementés portant des habits ERC-20 ?
#Newt $LAB $NEWT
J’ai passé du temps à réfléchir aux stablecoins en tant que monnaie pour les paiements transfrontaliers, et une question n’a cessé de revenir.
Le même jeton peut-il suivre des règles différentes sans compromettre l’expérience de paiement ?
En chaîne, un transfert de stablecoin semble simple.
Même actif.
Même contrat.
Même logique de règlement.
Mais dans le monde réel, un paiement n’est rarement qu’un simple paiement. L’expéditeur peut être soumis à une juridiction, le destinataire à une autre, le montant peut franchir un seuil de déclaration, et le corridor lui-même peut impliquer des attentes de conformité différentes.
C’est là que le <@NewtonProtocol > devient intéressant pour moi.
L’angle du Newton’s Mainnet Beta n’est pas seulement une question de vérification des portefeuilles en théorie. Il place l’évaluation des politiques avant le règlement, de sorte que les règles puissent faire partie du chemin de paiement réel plutôt que de rester un rapport une fois l’argent déjà déplacé.
Cela change la conception.
Un réseau de paiement n’a pas besoin de traiter chaque transfert de stablecoin comme étant juridiquement identique. Il peut appliquer une logique de politique différente en fonction du contexte de l’expéditeur, du contexte du destinataire, du montant, du corridor, de l’éligibilité ou de l’exposition aux risques.
Au début, cela ressemble à davantage de friction.
Mais peut-être que l’adoption transfrontalière des stablecoins nécessite ce type de couche si elle veut dépasser les utilisateurs nés avec la crypto. Les rails de paiement existants fonctionnent déjà au sein de logiques propres à chaque juridiction. La différence est que Newton cherche à rendre ces règles programmables et applicables au niveau de la transaction.
Pourtant, le compromis est bien réel.
Si les règles sont trop souples, les réseaux de paiement régulés ne feront pas confiance au système. Si les règles sont trop strictes, les stablecoins risquent de perdre la sensation ouverte et mondiale qui les a rendus puissants à l’origine.
C’est la partie que je n’ai pas encore entièrement tranchée.
L’autorisation basée sur les juridictions rend-elle les paiements en stablecoin plus utilisables pour le monde réel, ou est-ce qu’elle transforme progressivement la monnaie ouverte en frontières programmables ?
<#Newt > <$NEWT $LAB >
Le même jeton peut-il suivre des règles différentes sans compromettre l’expérience de paiement ?
En chaîne, un transfert de stablecoin semble simple.
Même actif.
Même contrat.
Même logique de règlement.
Mais dans le monde réel, un paiement n’est rarement qu’un simple paiement. L’expéditeur peut être soumis à une juridiction, le destinataire à une autre, le montant peut franchir un seuil de déclaration, et le corridor lui-même peut impliquer des attentes de conformité différentes.
C’est là que le <@NewtonProtocol > devient intéressant pour moi.
L’angle du Newton’s Mainnet Beta n’est pas seulement une question de vérification des portefeuilles en théorie. Il place l’évaluation des politiques avant le règlement, de sorte que les règles puissent faire partie du chemin de paiement réel plutôt que de rester un rapport une fois l’argent déjà déplacé.
Cela change la conception.
Un réseau de paiement n’a pas besoin de traiter chaque transfert de stablecoin comme étant juridiquement identique. Il peut appliquer une logique de politique différente en fonction du contexte de l’expéditeur, du contexte du destinataire, du montant, du corridor, de l’éligibilité ou de l’exposition aux risques.
Au début, cela ressemble à davantage de friction.
Mais peut-être que l’adoption transfrontalière des stablecoins nécessite ce type de couche si elle veut dépasser les utilisateurs nés avec la crypto. Les rails de paiement existants fonctionnent déjà au sein de logiques propres à chaque juridiction. La différence est que Newton cherche à rendre ces règles programmables et applicables au niveau de la transaction.
Pourtant, le compromis est bien réel.
Si les règles sont trop souples, les réseaux de paiement régulés ne feront pas confiance au système. Si les règles sont trop strictes, les stablecoins risquent de perdre la sensation ouverte et mondiale qui les a rendus puissants à l’origine.
C’est la partie que je n’ai pas encore entièrement tranchée.
L’autorisation basée sur les juridictions rend-elle les paiements en stablecoin plus utilisables pour le monde réel, ou est-ce qu’elle transforme progressivement la monnaie ouverte en frontières programmables ?
<#Newt > <$NEWT $LAB >
Vérifié
Je reviens sans cesse à une partie mal à l’aise de la finance inter-chaînes :
Les ponts ne déplacent pas seulement des actifs.
Ils déplacent aussi le risque.
La plupart des gens parlent du inter-chaînes comme si les seuls problèmes étaient la vitesse, les frais et la liquidité. Les actifs peuvent-ils bouger plus vite ? Les utilisateurs peuvent-ils éviter les itinéraires coûteux ? La DeFi peut-elle sembler plus fluide entre les réseaux ?
Ces questions comptent.
Mais il y a un problème plus discret en dessous.
Quand un actif passe d’une chaîne à une autre, les règles qui le protègent ne changent pas toujours avec la même intensité.
Une chaîne peut appliquer des contrôles de politique stricts. Une autre peut dépendre de contrôles au niveau de l’application. Une autre peut seulement détecter une activité suspecte après que la transaction a déjà eu lieu.
Cela crée une faiblesse étrange.
Le risque n’a pas besoin de briser la partie la plus solide du système. Il lui suffit de trouver l’itinéraire le plus faible.
C’est à cet endroit que le @NewtonProtocol devient intéressant pour moi.
Newton Mainnet Beta ne vise pas seulement à ajouter une couche supplémentaire à la DeFi. Il s’agit d’une autorisation avant le règlement. Un intent de transaction peut être vérifié d’abord par rapport à une politique active, puis recevoir une attestation signée de réussite/échec avant l’exécution.
Cette différence compte.
La surveillance vous indique ce qui s’est mal passé après que l’argent a été déplacé.
L’autorisation demande si l’argent doit en premier lieu être déplacé.
Le vrai défi est de savoir si les applications accepteront une infrastructure de politique partagée plutôt que de construire des contrôles isolés. La crypto adore la composition, mais chaque équipe veut encore contrôler ses propres limites.
C’est ce que Newton doit encore prouver.
Mais si les actifs deviennent inter-chaînes par défaut, la politique ne peut pas rester enfermée dans une seule chaîne.
Parce que le risque du futur n’est pas seulement constitué de mauvaises transactions.
Ce sont de mauvaises transactions qui trouvent la chaîne la plus facile à dissimuler.
$LAB $NEWT #Newt
Les ponts ne déplacent pas seulement des actifs.
Ils déplacent aussi le risque.
La plupart des gens parlent du inter-chaînes comme si les seuls problèmes étaient la vitesse, les frais et la liquidité. Les actifs peuvent-ils bouger plus vite ? Les utilisateurs peuvent-ils éviter les itinéraires coûteux ? La DeFi peut-elle sembler plus fluide entre les réseaux ?
Ces questions comptent.
Mais il y a un problème plus discret en dessous.
Quand un actif passe d’une chaîne à une autre, les règles qui le protègent ne changent pas toujours avec la même intensité.
Une chaîne peut appliquer des contrôles de politique stricts. Une autre peut dépendre de contrôles au niveau de l’application. Une autre peut seulement détecter une activité suspecte après que la transaction a déjà eu lieu.
Cela crée une faiblesse étrange.
Le risque n’a pas besoin de briser la partie la plus solide du système. Il lui suffit de trouver l’itinéraire le plus faible.
C’est à cet endroit que le @NewtonProtocol devient intéressant pour moi.
Newton Mainnet Beta ne vise pas seulement à ajouter une couche supplémentaire à la DeFi. Il s’agit d’une autorisation avant le règlement. Un intent de transaction peut être vérifié d’abord par rapport à une politique active, puis recevoir une attestation signée de réussite/échec avant l’exécution.
Cette différence compte.
La surveillance vous indique ce qui s’est mal passé après que l’argent a été déplacé.
L’autorisation demande si l’argent doit en premier lieu être déplacé.
Le vrai défi est de savoir si les applications accepteront une infrastructure de politique partagée plutôt que de construire des contrôles isolés. La crypto adore la composition, mais chaque équipe veut encore contrôler ses propres limites.
C’est ce que Newton doit encore prouver.
Mais si les actifs deviennent inter-chaînes par défaut, la politique ne peut pas rester enfermée dans une seule chaîne.
Parce que le risque du futur n’est pas seulement constitué de mauvaises transactions.
Ce sont de mauvaises transactions qui trouvent la chaîne la plus facile à dissimuler.
$LAB $NEWT #Newt
Vérifié
Les anciens ont une formule : « le pouvoir du roi l’emporte moins que la coutume du village. »
Je pense que la DeFi, c’est pareil.
Un smart contract ressemble à une réglementation écrite publiquement : tout le monde peut la voir, tout le monde peut la vérifier. Mais chaque application a aussi sa propre couche de conditions. Quelle “vidéo” est utilisée, quels sont les plafonds, quelles zones sont autorisées, comment gérer le cas où l’oracle tombe en erreur, à partir de quel score de risque il faut bloquer les transactions.
Le problème, c’est que ces conditions sont souvent dispersées. Un peu dans le frontend. Un peu dans le backend. Un peu dans la configuration admin. Un peu directement “injecté” dans le contract. Plus il y a de couches de rustines comme ça, plus le système devient difficile à auditer et difficile à expliquer quand une transaction est refusée.
C’est justement pour ça que je trouve le @NewtonProtocol particulièrement remarquable.
Newton utilise Rego/OPA pour transformer ces conditions en une couche de policy séparée, vérifiée avant le règlement. La transaction entre, le réseau operator vérifie la policy, renvoie une attestation signée “pass/fail”, puis le smart contract décide seulement ensuite s’il faut l’exécuter ou non.
Comme une voiture qui descend une pente : le moteur tourne bien ne suffit pas. Il lui faut aussi des freins qui sachent fonctionner au bon moment. Un vault DeFi, c’est pareil : le contract peut fonctionner correctement, mais si la santé de l’oracle est mauvaise, si le levier dépasse le seuil, ou si le wallet ne remplit pas les conditions, le système doit savoir quand il faut arrêter de laisser sortir l’argent.
J’appelle ça la Stop Logic.
Cette couche de logique aide le smart contract non seulement à savoir exécuter, mais aussi à savoir quand s’arrêter.
Mais cette approche a aussi un piège. Quand le refus de transaction est décidé par la policy, la question ne se limite pas à “le contract a-t-il été audité ?”. La question, c’est plutôt : qui a écrit la policy, qui la met à jour, et est-ce que l’utilisateur comprend pourquoi il a été bloqué.
Le meilleur smart contract, c’est celui qui sait exécuter.
Mais une DeFi mature a besoin de plus que quelque chose qui sait exécuter.
Elle a besoin de quelque chose qui sait s’arrêter.
$NEWT $LAB #Newt
Je pense que la DeFi, c’est pareil.
Un smart contract ressemble à une réglementation écrite publiquement : tout le monde peut la voir, tout le monde peut la vérifier. Mais chaque application a aussi sa propre couche de conditions. Quelle “vidéo” est utilisée, quels sont les plafonds, quelles zones sont autorisées, comment gérer le cas où l’oracle tombe en erreur, à partir de quel score de risque il faut bloquer les transactions.
Le problème, c’est que ces conditions sont souvent dispersées. Un peu dans le frontend. Un peu dans le backend. Un peu dans la configuration admin. Un peu directement “injecté” dans le contract. Plus il y a de couches de rustines comme ça, plus le système devient difficile à auditer et difficile à expliquer quand une transaction est refusée.
C’est justement pour ça que je trouve le @NewtonProtocol particulièrement remarquable.
Newton utilise Rego/OPA pour transformer ces conditions en une couche de policy séparée, vérifiée avant le règlement. La transaction entre, le réseau operator vérifie la policy, renvoie une attestation signée “pass/fail”, puis le smart contract décide seulement ensuite s’il faut l’exécuter ou non.
Comme une voiture qui descend une pente : le moteur tourne bien ne suffit pas. Il lui faut aussi des freins qui sachent fonctionner au bon moment. Un vault DeFi, c’est pareil : le contract peut fonctionner correctement, mais si la santé de l’oracle est mauvaise, si le levier dépasse le seuil, ou si le wallet ne remplit pas les conditions, le système doit savoir quand il faut arrêter de laisser sortir l’argent.
J’appelle ça la Stop Logic.
Cette couche de logique aide le smart contract non seulement à savoir exécuter, mais aussi à savoir quand s’arrêter.
Mais cette approche a aussi un piège. Quand le refus de transaction est décidé par la policy, la question ne se limite pas à “le contract a-t-il été audité ?”. La question, c’est plutôt : qui a écrit la policy, qui la met à jour, et est-ce que l’utilisateur comprend pourquoi il a été bloqué.
Le meilleur smart contract, c’est celui qui sait exécuter.
Mais une DeFi mature a besoin de plus que quelque chose qui sait exécuter.
Elle a besoin de quelque chose qui sait s’arrêter.
$NEWT $LAB #Newt
Vérifié
Même policy, mais avec des paramètres différents : Newton est-il en train de réutiliser la loi ou de reconditionner la confiance ?
Au début, je pensais que la policy dans le protocole Newton ressemblait à un ensemble de règles fixe : écrit une fois, mis en ligne, puis toute application qui l’utilise obtient le même type de contrôle.
Mais en y regardant de plus près, ce n’est pas aussi simple.
Newton sépare la logique Rego de la partie configuration de chaque PolicyClient. Autrement dit, une même policy peut être réutilisée, mais chaque application y associe ses propres paramètres : seuil différent, limite d’exposition différente, liste d’adresses approuvées différente.
C’est un point intéressant.
Et c’est aussi un point à questionner.
Car une règle identique ne signifie pas un niveau de confiance identique. Un vault peut partager une risk policy, mais imposer des limites plus larges. Une autre app utilise la même logique, mais resserre les paramètres.
Vu de l’extérieur, tout semble être « passé par policy », mais la frontière d’exécution réelle se trouve dans la configuration.
Je l’appelle Parameter Trust.
La confiance ne se trouve pas seulement dans la loi.
Elle se trouve chez la personne autorisée à faire tourner la loi avec quels paramètres.
Même expireAfter n’est pas aussi simple qu’un détail technique. S’il est trop court, l’utilisateur peut ne pas avoir le temps de terminer la transaction. S’il est trop long, l’approbation dure plus longtemps : la fenêtre de sécurité s’élargit.
Le bon côté de @NewtonProtocol , c’est que chaque mise à jour de la configuration crée un nouvel policyId, rendant la frontière du changement visible. Mais le fait de la voir ne veut pas dire qu’elle est comprise. L’utilisateur doit toujours savoir, derrière ce nouveau policyId, ce qui a réellement changé.
Avec $NEWT , je ne me contenterai pas de regarder le nombre de policies réutilisées.
Je veux voir qui contrôle les paramètres.
Car une policy réutilisable ne garantit pas une confiance réutilisable. Un même ensemble de lois peut produire deux niveaux de sécurité très différents, selon qui tient et ajuste les paramètres.
#Newt $NFP
Au début, je pensais que la policy dans le protocole Newton ressemblait à un ensemble de règles fixe : écrit une fois, mis en ligne, puis toute application qui l’utilise obtient le même type de contrôle.
Mais en y regardant de plus près, ce n’est pas aussi simple.
Newton sépare la logique Rego de la partie configuration de chaque PolicyClient. Autrement dit, une même policy peut être réutilisée, mais chaque application y associe ses propres paramètres : seuil différent, limite d’exposition différente, liste d’adresses approuvées différente.
C’est un point intéressant.
Et c’est aussi un point à questionner.
Car une règle identique ne signifie pas un niveau de confiance identique. Un vault peut partager une risk policy, mais imposer des limites plus larges. Une autre app utilise la même logique, mais resserre les paramètres.
Vu de l’extérieur, tout semble être « passé par policy », mais la frontière d’exécution réelle se trouve dans la configuration.
Je l’appelle Parameter Trust.
La confiance ne se trouve pas seulement dans la loi.
Elle se trouve chez la personne autorisée à faire tourner la loi avec quels paramètres.
Même expireAfter n’est pas aussi simple qu’un détail technique. S’il est trop court, l’utilisateur peut ne pas avoir le temps de terminer la transaction. S’il est trop long, l’approbation dure plus longtemps : la fenêtre de sécurité s’élargit.
Le bon côté de @NewtonProtocol , c’est que chaque mise à jour de la configuration crée un nouvel policyId, rendant la frontière du changement visible. Mais le fait de la voir ne veut pas dire qu’elle est comprise. L’utilisateur doit toujours savoir, derrière ce nouveau policyId, ce qui a réellement changé.
Avec $NEWT , je ne me contenterai pas de regarder le nombre de policies réutilisées.
Je veux voir qui contrôle les paramètres.
Car une policy réutilisable ne garantit pas une confiance réutilisable. Un même ensemble de lois peut produire deux niveaux de sécurité très différents, selon qui tient et ajuste les paramètres.
#Newt $NFP
Vérifié
Si la transaction est redemandée après 6 mois, le protocole Newton peut-il fournir un reçu ?
L’autre jour, je suis allé faire une demande de garantie pour mon casque. Le personnel a demandé la facture. Je me souviens très clairement que je l’ai acheté là-bas, je me rappelle même le jour de l’achat, et aussi le vendeur qui était derrière le comptoir. Mais m’en souvenir ne m’aide pas. S’il n’y a pas de reçu, toutes les explications deviennent forcément du ressenti.
Je pense alors à l’histoire onchain. Là-bas, toutes les transactions ont un historique, mais toutes les transactions n’ont pas forcément une raison.
La blockchain est très douée pour enregistrer les transactions. Qui envoie, combien, à quel moment, quel contract reçoit. Mais pour les flux de fonds institutionnels, ce n’est pas suffisant. Car l’historique ne répond qu’à ce qui s’est passé.
Il ne répond pas encore à la question plus difficile :
Pourquoi cette transaction est-elle autorisée à avoir lieu ?
C’est un point que je trouve @NewtonProtocol assez intéressant. Newton ne veut pas seulement que la transaction puisse être vérifiée avant le settlement. Il peut aussi créer une sorte de reçu de conformité : une preuve que la policy a été vérifiée, que les conditions sont passées, que l’attestation a été signée, puis seulement ensuite le smart contract autorise la transaction à continuer.
Newton ne fait pas que permettre au DeFi de dire « ça marche ».
Newton aide le DeFi à conserver la preuve de ce « oui ».
Ce point semble petit, mais il est très important pour les stablecoins, les RWA, les vaults ou les organisations. Parce que la grande finance ne fonctionne pas avec la formule « faites-moi confiance ». Elle a besoin d’une trace d’audit suffisamment claire pour que, plus tard, quand on redemandera des comptes, le système n’ait pas à fouiller des logs, à donner des explications à l’oral, ou à s’appuyer sur la réputation d’un intermédiaire.
Avec $NEWT , je pourrai voir de vrais reçus de conformité, pas seulement des chiffres destinés à rappeler un nom.
Parce qu’un DeFi mature n’existe pas quand toutes les transactions s’exécutent juste plus vite.
Mais quand chaque transaction importante laisse une raison suffisamment claire pour être autorisée à fonctionner.
#Newt
$VOOI $BASED
L’autre jour, je suis allé faire une demande de garantie pour mon casque. Le personnel a demandé la facture. Je me souviens très clairement que je l’ai acheté là-bas, je me rappelle même le jour de l’achat, et aussi le vendeur qui était derrière le comptoir. Mais m’en souvenir ne m’aide pas. S’il n’y a pas de reçu, toutes les explications deviennent forcément du ressenti.
Je pense alors à l’histoire onchain. Là-bas, toutes les transactions ont un historique, mais toutes les transactions n’ont pas forcément une raison.
La blockchain est très douée pour enregistrer les transactions. Qui envoie, combien, à quel moment, quel contract reçoit. Mais pour les flux de fonds institutionnels, ce n’est pas suffisant. Car l’historique ne répond qu’à ce qui s’est passé.
Il ne répond pas encore à la question plus difficile :
Pourquoi cette transaction est-elle autorisée à avoir lieu ?
C’est un point que je trouve @NewtonProtocol assez intéressant. Newton ne veut pas seulement que la transaction puisse être vérifiée avant le settlement. Il peut aussi créer une sorte de reçu de conformité : une preuve que la policy a été vérifiée, que les conditions sont passées, que l’attestation a été signée, puis seulement ensuite le smart contract autorise la transaction à continuer.
Newton ne fait pas que permettre au DeFi de dire « ça marche ».
Newton aide le DeFi à conserver la preuve de ce « oui ».
Ce point semble petit, mais il est très important pour les stablecoins, les RWA, les vaults ou les organisations. Parce que la grande finance ne fonctionne pas avec la formule « faites-moi confiance ». Elle a besoin d’une trace d’audit suffisamment claire pour que, plus tard, quand on redemandera des comptes, le système n’ait pas à fouiller des logs, à donner des explications à l’oral, ou à s’appuyer sur la réputation d’un intermédiaire.
Avec $NEWT , je pourrai voir de vrais reçus de conformité, pas seulement des chiffres destinés à rappeler un nom.
Parce qu’un DeFi mature n’existe pas quand toutes les transactions s’exécutent juste plus vite.
Mais quand chaque transaction importante laisse une raison suffisamment claire pour être autorisée à fonctionner.
#Newt
$VOOI $BASED
Connectez-vous pour découvrir plus de contenu