Prototype A - simulateur
Détecter de faux dusts, choisir une ONG fictive, signer une intention locale factice, calculer frais et produire une preuve de lot simulée.
Technique
La bonne architecture commence hors chaîne : consentir, limiter, agréger, prouver.
DustEthic ne doit pas courir après chaque protocole. Le projet doit sélectionner les briques qui réduisent les frais, améliorent l’UX et renforcent la preuve sans créer de custody opaque.
Radar technique
Briques à utiliser, tester ou surveiller.
| Brique | Statut | Utilité DustEthic | Risque / règle |
|---|---|---|---|
| x402 / HTTP 402 | à prototyper | Exprimer une demande de micro-don web ou agentique avec instructions de paiement. | Ne pas réduire DustEthic à un paywall. Protéger métadonnées, replay et preuve de lot. |
| ERC-4337 | final | Smart accounts, UserOperations, bundlers et paymasters pour sponsoriser ou mutualiser le gas. | Dépendance infrastructurelle aux bundlers/paymasters à documenter. |
| EIP-7702 | final | Batching, sponsoring et permissions plus fines pour comptes existants. | Délégation de code sensible : jamais de signature incompréhensible ou illimitée. |
| EIP-5792 | final | API wallet pour envoyer plusieurs calls et suivre le statut. | Prévoir fallback si le wallet ne supporte pas les capacités. |
| ERC-7677 | review | Communication standardisée wallet - paymaster web service. | À utiliser seulement après revue d’implémentation et politique sponsor claire. |
| ERC-7683 | draft | Intents cross-chain, solvers et résolution multi-réseaux. | Pas base de production tant que le standard reste en draft. |
| CCTP | USDC | Transferts natifs USDC entre chaînes sans wrapped token. | Utile pour USDC, pas pour tous les actifs. Dépend de la disponibilité réseau. |
Prototype minimal
Le prochain vrai prototype ne doit pas collecter d’argent.
Il doit prouver que le modèle est compréhensible et vérifiable avant de toucher un seul fonds réel.
Prototype B - testnet
Répéter le flux sur testnet avec actifs test, paymaster ou transaction classique, puis publier hash et preuve de lot.
Prototype C - ONG pilote
Valider les données dont une ONG a besoin : wallet officiel, preuve, export, comptabilité, reçu fiscal éventuel.
Prototype D - audit
Audit contrats, relayeurs, UX de signature, risques juridiques et limites fiscales avant toute exécution réelle.
Architecture
Flux recommandé : intention d’abord, transfert ensuite.
Le donateur ne devrait jamais signer une autorisation infinie. L’intention doit limiter montant, actif, réseau, bénéficiaire, durée et plafond de frais.
1wallet_getCapabilities
2intention signée EIP-712 ou équivalent
3simulation gas + plafond
4agrégation jusqu’au seuil
5exécution + preuve publique
Règles de sécurité
Le projet doit être plus strict que le marketing Web3 moyen.
Autorisation minimale
Pas d’approbation illimitée, pas de signature opaque, expiration courte et montant borné.
Tokens refusés
Refuser par défaut tokens illiquides, taxés, piégés, honeypots ou sans support explorateur raisonnable.
Preuve avant communication
Ne jamais annoncer un impact ou un montant net sans hash, calcul des frais et version du standard.