Partir d’un problème concret d’utilisation

Choisissez la difficulté à résoudre : acquérir du gas avant une première opération, répéter des approbations ou réussir une récupération trop complexe. Décrivez le parcours souhaité avant de choisir l’infrastructure. ERC-4337 organise des opérations de comptes intelligents autour de UserOperations et de services associés. Il ne définit pas à lui seul toutes les permissions ou possibilités de récupération nécessaires. Demandez au fournisseur de rattacher chaque avantage à une capacité livrée, à un réglage ou à un développement supplémentaire. Le nom d’une norme ne constitue pas un cahier des charges complet.

Montrer ce que le client autorise

Un accueil simplifié doit toujours rendre les pouvoirs compréhensibles. Identifiez le signataire, le compte contrôlé et le périmètre de l’action approuvée. Si plusieurs appels sont regroupés, résumez leur effet commun et rendez les détails utiles accessibles. Expliquez les étapes métier qui restent en dehors de la transaction du compte. Pendant la revue, demandez à une personne non impliquée de reformuler ce qu’elle pense avoir accepté. Cet exercice met souvent en évidence l’écart entre une demande techniquement correcte et une explication réellement utilisable par le client.

Encadrer le service de prise en charge des frais

Un paymaster peut permettre le sponsoring du gas dans un parcours ERC-4337 ; le produit doit encore décider des bénéficiaires et du payeur. Fixez budgets, actions couvertes, contrôles d’usage et comportement en cas d’indisponibilité. Une première opération offerte ne doit pas suggérer une gratuité illimitée. Affichez tout paiement demandé avant approbation, notamment lorsqu’un parcours de remplacement modifie le coût. Prévoyez aussi la console opérationnelle : suivi des dépenses, investigation d’une consommation inattendue et suspension d’une règle sans bloquer involontairement les autres actions que les comptes doivent conserver.

Rendre les permissions limitées vérifiables

Si le compte choisi permet des permissions de session, définissez destinations, opérations, plafonds, durée et révocation dans des termes consultables. Une session n’est pas sans conséquence simplement parce qu’elle réduit les confirmations. Écrivez un exemple autorisé et un exemple interdit, puis vérifiez-les avec les règles effectivement déployées. Montrez où consulter les permissions actives. Prévoyez leur expiration pendant une tâche. Évitez de demander discrètement un pouvoir plus large pour rendre une démonstration fluide : la limite promise au client doit rester celle que le système applique réellement.

Spécifier la récupération indépendamment de l’accès courant

Le dispositif doit nommer les participants, les conditions de remplacement d’un signataire et les éventuels délais ou notifications. Un écran familier de connexion par courriel n’explique pas à lui seul les pouvoirs sous-jacents. Distinguez appareil perdu et appareil compromis, avec les possibilités de contester un changement en attente lorsqu’elles existent. Documentez les limites sans promettre une récupération universelle. La livraison doit comprendre une procédure opérationnelle et un texte destiné au client cohérents avec les contrats et services réels. Testez tout le parcours, pas uniquement son bouton de démarrage.

Évaluer les dépendances avec le produit

Demandez une matrice des réseaux et composants pris en charge : implémentation du compte, compatibilité EntryPoint, bundler, paymaster et services applicatifs. Consignez les versions déployées et le responsable de leurs évolutions. Testez panne du prestataire, refus de sponsoring, permissions expirées, opération rejetée et échec de déploiement du compte. L’historique doit relier la demande applicative à son résultat sur la chaîne. Un bon portefeuille intelligent ne se définit pas seulement par un nombre minimal d’étapes : son parcours simplifié reste explicable lorsque les services qui l’accompagnent fonctionnent mal.