Un smart contract ne « voit » pas un compteur. Un oracle publie une valeur (MWh, m³, prix) que le contrat consomme. La qualité du système dépend de la source (télémétrie, certificateur, marché), de la fréquence, des seuils d'erreur et de qui peut contester.
Pour les ressources, les échecs classiques sont : oracle unique, retard de publication, unité mal définie (brut vs net), et absence de procédure de dispute. Un design sérieux documente le fallback off-chain autant que le happy path on-chain.
— Le contrat consomme une valeur publiée — il ne mesure pas
Les patterns utiles pour RWA ressources : mint conditionné à une preuve de droit, settlement périodique sur oracle, pause/circuit-breaker opérationnel, et rôles séparés (émetteur, opérateur oracle, gardien pause). Éviter les admin keys omnipotentes sans audit trail.
Les builders AUROS peuvent s'entraîner sur des labs produit — ce ne sont pas des contrats de production ni une invitation à déployer sans revue juridique.
La crédibilité d'un oracle dépend de la chaîne de mesure : capteur calibré, agrégation, horodatage, et qui peut contester. En énergie, distinguer brut / net / exporté. En eau, volume vs qualité vs disponibilité. Les crédits verts (REC, carbone) ont déjà des registres — la tokenisation doit référencer ces IDs, pas les inventer.
Le lab /green et /green/csrd-check illustrent des contrôles indicatifs. Ce ne sont pas des vérifications d'émetteur ni un agrément CSRD.
Contenu éducatif AUROS Academy — ne constitue pas un conseil d'investissement, juridique ou réglementaire. Pas d'agrément État / AMF / CSSF. Pas de Qualiopi ni affiliation universitaire revendiquée. Credentials éducatifs AUROS uniquement.