Développement de smart contract pour des règles que votre équipe peut examiner

Par où commencer le développement d'un smart contract ?

Commencez par les actions que vos utilisateurs doivent effectuer et les règles qui régissent chacune d'elles. Nous utilisons ces détails pour décrire le comportement du contrat avant d'écrire le code.

1. Nommez l'action utilisateur. Décrivez ce que quelqu'un doit faire, par exemple réclamer une allocation ou déposer un actif.
2. Définissez les conditions. Notez quand l'action est autorisée et ce qui doit se passer quand elle ne l'est pas.
3. Listez les rôles. Identifiez qui peut utiliser chaque fonction et qui, le cas échéant, peut gérer les paramètres.
4. Marquez les dépendances. Notez les contrats, actifs, services ou travaux d'interface connexes.
5. Examinez le comportement. Convenez de cas de test qui reflètent une utilisation normale et des actions restreintes.

Cela donne à votre équipe une description partagée à examiner avant l'implémentation. Cela nous aide également à repérer tôt les règles produit non décidées, alors que les modifications sont encore plus faciles à discuter. Pour un travail connexe sur les tokens, voir création et déploiement de token.

Si les utilisateurs ont besoin d'une interface on-chain, le développement de dApp peut faire partie du même plan. Vous n'avez pas besoin d'avoir réglé chaque choix technique avant de nous parler. Apportez les décisions que vous avez prises, marquez celles qui sont ouvertes, et nous vous aiderons à séparer les questions produit des détails d'implémentation.

Gardez le contrat proche du fonctionnement de votre communauté

Un contrat est plus facile à planifier lorsque ses règles correspondent aux actions réelles que les gens doivent effectuer. Un peu de contexte sur vos utilisateurs nous aide à établir ce lien sans supposer un modèle standard de token ou de récompense.

Imaginez un serveur Discord avec un administrateur à temps partiel, qui décide par quel canal commencer. L'équipe réfléchit également à la manière dont les contributeurs recevront une allocation de token au fil du temps. Nous aiderions d'abord à décrire les règles d'allocation, qui peut réclamer, et de quoi l'administrateur est responsable. Ensuite, nous séparerions ces règles contractuelles des décisions sur la façon dont la communauté partage les mises à jour.

Par exemple, disons que votre produit a besoin de staking en plus d'un token. Nous demanderions comment les dépôts et les retraits doivent fonctionner, comment les récompenses sont représentées, et sur quels actifs ou autres services le plan repose. Nous enregistrons les réponses comme un comportement à examiner, et non comme une conception économique présumée.

Ces limites sont importantes lorsque des travaux adjacents sont impliqués. Nous pouvons coordonner les exigences du contrat avec un site Web3 et une landing page, ou planifier la passation avec le développement de wallet crypto. Si votre équipe a déjà des développeurs, nous pouvons convenir de qui est responsable de chaque partie connectée avant le début du travail.

Une passation que votre équipe peut suivre

Vous recevez le code et les notes de travail nécessaires pour comprendre le comportement convenu du contrat. Nous confirmons le contenu avec vous avant le développement, afin que la passation corresponde au produit plutôt que de suivre une liste de contrôle générique. Pour des besoins produit plus larges, voir développement Web3.

Un contrat de vesting peut nécessiter une description claire des conditions d'allocation et de réclamation. Un développement de staking peut nécessiter l'enregistrement des conditions de dépôt, de retrait et de récompense. Nous façonnons les supports écrits autour des fonctions que vous approuvez, afin que les examinateurs puissent comparer les règles énoncées avec les tests et le code. Cela peut également aider votre équipe à planifier le travail d'interface avec le développement de dApp.

Si le contrat fait partie d'un produit plus vaste, nous notons également où s'arrêtent ses responsabilités. Cela facilite la planification du travail connexe.

Que se passe-t-il entre le premier examen et la mise en production ?

Nous passons des décisions produit à une spécification examinée, puis développons, testons et préparons la passation convenue. Votre équipe dispose de points clairs pour vérifier le comportement avant qu'une mise en production ne soit envisagée.

Nous commençons par examiner l'objectif produit, la chaîne, les utilisateurs et les systèmes connectés. Une checklist de démarrage nous aide à rassembler les règles du contrat, à identifier les choix ouverts et à confirmer qui les approuvera. Une fois que vous approuvez le comportement écrit, nous implémentons les fonctions convenues et partageons l'avancement avec votre contact technique.

Les tests suivent les cas convenus lors de la conception. Si la coordination d'audit est incluse, nous préparons les supports d'examen, acheminons les questions techniques et organisons les réponses aux constatations. Lorsque des modifications sont convenues, nous mettons à jour le code concerné et réexécutons les tests associés. Nous gardons les décisions visibles dans une note d'avancement écrite, afin que votre équipe puisse voir ce qui est prêt et ce qui nécessite encore un examen.

La chaîne et la conception du contrat déterminent les contrôles de mise en production disponibles. Les tests ne couvrent que les cas qu'ils décrivent. Un audit indépendant est limité à son examen convenu. Après le déploiement, la possibilité de modifier le code dépend de la conception et de la chaîne.

Planifiez le travail Web3 connexe autour du périmètre du contrat

Développez les composants connexes ensemble lorsque le contrat dépend d'un token, d'une interface ou d'un flux de wallet. Le fait de convenir de qui est responsable de chaque partie aide votre équipe à éviter les écarts entre le comportement on-chain et le produit qui l'entoure.

Un premier contrôle utile consiste à lister les parties déjà planifiées et à nommer un responsable pour chacune. Votre contrat peut être lié à un lancement de token, une interface utilisateur, un flux de wallet ou un autre service. Nous pouvons cartographier ces connexions avec vos développeurs, puis garder le travail sur le contrat distinct de tout ce qu'une autre équipe développera.

Nous donnerons à votre projet un contact technique unique et une note d'avancement écrite. Cette personne suit les questions ouvertes, partage le travail pour examen et garde la prochaine décision claire. Apportez-nous ces 3 points de départ :

• Le plan de votre produit et les actions utilisateur que le contrat doit prendre en charge.
• La chaîne cible, si elle est choisie, ainsi que tout code existant ou notes techniques.
• Vos règles actuelles de vesting, staking ou token, y compris les questions sans réponse.

Envoyez ces supports à Brand Community. Nous les examinerons avec vous, identifierons les décisions à régler et préparerons un plan clair pour le développement du contrat.

Comment ça marche

1. Cartographier le périmètre du contratNous examinons l'objectif produit, les utilisateurs, la chaîne cible et les parties connectées. Vous identifiez les décisions qui nécessitent une réponse du responsable produit.
2. Convenir du comportement écritNous enregistrons les fonctions, les rôles, les conditions et les cas de test. Votre équipe examine la description avant le début de l'implémentation.
3. Développer et tester les fonctionsNous implémentons le comportement convenu et préparons des tests pour les actions attendues et restreintes. Nous partageons l'avancement et les questions ouvertes avec votre contact technique.
4. Coordonner un examen indépendantLorsque la coordination d'audit est incluse, nous préparons les supports d'examen et organisons les réponses aux constatations. Nous apportons les modifications convenues et réexécutons les tests associés.
5. Préparer la mise en production et la passationNous fournissons le code convenu, les notes de test et les supports de déploiement. Votre équipe confirme la responsabilité de la mise en production et vérifie les détails du déploiement.