Développement Web3 pour des produits, pas pour des présentations
Des produits on-chain qui ne détiennent aucune clé, lisibles par des non-initiés, livrés avec le code.
Nous construisons et exploitons nos propres produits on-chain, ce qui est une discipline différente d'en construire un pour un lancement. Cela signifie que nous avons déjà rencontré ce qui n'apparaît qu'en production : un fournisseur RPC qui va mal, un portefeuille qui change de comportement à une mise à jour, un utilisateur qui ignore ce qu'est un nonce et n'a pas à le savoir.
Les décisions qui comptent en premier
- La détention. Que votre produit détienne ou non les clés ou les fonds d'un utilisateur change le cadre réglementaire, la question de l'assurance et l'ingénierie. Par défaut, chez nous, il ne détient rien.
- Ce qui doit réellement être sur la chaîne. L'essentiel d'un produit Web3 est du logiciel ordinaire, et mettre quelque chose on-chain parce que cela sonne mieux, c'est acheter des bugs irréversibles.
- La possibilité de mise à jour. Un contrat modifiable exige une gouvernance ; un contrat figé exige des certitudes avant déploiement. Les deux se défendent, le silence non.
- Qui paie les frais de réseau, et ce que dit l'interface quand le réseau est congestionné et que le montant double entre l'estimation et la confirmation.
Ce que nous construisons
- Des interfaces produit au-dessus de protocoles existants : staking, portefeuille, marché, utilisables par un non-spécialiste sans tutoriel.
- Des smart contracts quand le produit en a réellement besoin, écrits simplement, testés sur les cas d'échec plutôt que sur le chemin idéal.
- La moitié ingrate : l'indexation, des lectures on-chain qui restent rapides, des états de transaction qui survivent à un rafraîchissement, et un message clair en cas de réorganisation de chaîne.
- L'outillage de trésorerie et de token pour les équipes qui ont livré le produit et doivent maintenant l'exploiter.
Ce que cela coûte
- 6-12 semaines pour une interface produit sur un protocole existant
- audit budgété à part, avant que quoi que ce soit détienne de la valeur
- 0 clé de vos utilisateurs détenue par nous
Le produit doit être utilisable par quelqu'un à qui il est indifférent qu'il soit on-chain. C'est tout le test.
Questions fréquentes
Faut-il un token ?
Généralement non, et il vaut la peine de résister à la question tant que le produit ne fonctionne pas sans. Un token ajoute une exposition réglementaire, une dynamique de marché à gérer et un second emploi à plein temps. Quand il fait réellement partie du mécanisme, nous le construisons ; quand c'est un instrument de levée en quête de produit, nous le disons aussi.
Sur quelle chaîne construire ?
Là où sont déjà vos utilisateurs et votre liquidité, ce qui est rarement la chaîne au meilleur marketing développeur. Ce choix influe sur les frais, la finalité, l'outillage et sur qui pourra s'intégrer à vous plus tard. Nous travaillons sur les principaux écosystèmes et vous donnerons l'arbitrage par écrit plutôt qu'une préférence.
Comment gérez-vous la sécurité ?
Non-custodial par défaut, donc le pire cas est borné. Ensuite : des contrats aussi petits et lisibles que le produit le permet, des tests écrits sur la façon dont les choses cassent réellement, un audit externe pour tout ce qui détient de la valeur, et de la supervision après déploiement, parce qu'un contrat est un logiciel vivant que des gens ont un intérêt financier à casser.