75,41 M
transactions x402 / 30 jours
Activité déclarée par le site officiel x402 lors de l’étude du 27 juillet 2026 ; donnée dynamique.
Whitepaper technique · v0.3
La couche de confiance des agents financiers autonomes.
Proof of Method relie une méthode versionnée, une politique de risque, un reçu d’exécution et une attestation indépendante. L’objectif : prouver le processus qui a gouverné une action sans révéler la stratégie, les comptes ou les clés.
Statut : SWTK est en cours de conception et son lancement est prévu après testnet, audit indépendant et validation juridique. Aucun token n’est encore émis, aucune adresse de contrat n’est annoncée et aucune vente n’est ouverte.
SwissTokint
07
Infrastructure ouverte de risque
Recherche · gouvernance · communauté
Le problème de recherche
Rendre une méthode contrôlable sans révéler les données qu’elle doit protéger.
Les tableaux de résultats, alertes et votes sont faciles à publier mais difficiles à replacer dans leur contexte. Proof of Method vise une chaîne d’éléments vérifiables : une version de méthode, une empreinte des entrées, un résultat, une revue et une décision. Le registre n’atteste pas qu’une stratégie est rentable ; il permet seulement de vérifier qu’un processus déclaré existait à un instant donné et n’a pas été réécrit en silence.
Thèse de marché
Les agents savent déjà communiquer et payer. Leur responsabilité reste à construire.
A2A et MCP normalisent les interactions entre agents, x402 leurs paiements HTTP, ERC-8004 leur identité et leur validation. La niche SwissTokint est plus précise : des preuves de méthode et de risque pour les agents qui opèrent dans des environnements financiers à forte conséquence.
22 000
vendeurs x402 / 30 jours
Base observable pour une première estimation, pas un nombre de clients SwissTokint.
3 registres
ERC-8004
Identité, réputation et validation ; les incitations des vérificateurs restent à spécialiser.
4,20 / 5
score de la niche
Meilleur résultat de l’analyse interne face au token de bot, au marché de signaux et au calcul distribué.
Architecture proposée
Des empreintes publiques, des données privées et des vérifications indépendantes.
01
Engagement versionné
Le producteur publie l’empreinte d’une règle, de ses paramètres, de sa politique de données et de son code ou document versionné.
02
Reçu d’exécution
Un test, une simulation ou un événement de stratégie produit un reçu horodaté lié à la version engagée, sans publier les secrets ni les comptes.
03
Attestation de revue
Un relecteur indépendant peut signer une conclusion bornée : cohérence de format, reproductibilité partielle ou limites observées.
04
Vérification portable
Une application ou une personne recompose les éléments et vérifie les empreintes sans dépendre d’un tableau de bord propriétaire.
Niveaux de preuve
Chaque niveau dit exactement ce qu’il prouve — et ce qu’il ne prouve pas.
L0
Reçu signé
Le signataire a produit ce reçu à un instant donné.
Ne garantit pas que son contenu est exact.
L1
Engagement ancré
Le reçu existait avant l’ancrage et n’a pas été modifié.
Ne juge pas la qualité de la méthode.
L2
Attestation indépendante
Un tiers a contrôlé une affirmation bornée et publiée.
Ne prédit pas la performance future.
L3
Assurance renforcée
Un rejeu, un TEE ou une preuve ZK vérifie une propriété précise.
N’élimine pas tous les risques opérationnels.
Confidentialité par conception
Prouver l’éligibilité ou l’intégrité sans publier l’identité et les détails sensibles.
La première version ne doit pas stocker d’identités, de soldes, de clés d’exchange ou de paramètres propriétaires. Les données restent hors chaîne ; seules des empreintes et des attestations signées peuvent être publiées. Une phase de recherche évaluera ensuite les preuves à divulgation nulle de connaissance pour les cas où un membre doit prouver son éligibilité à voter sans relier publiquement son portefeuille à son vote.
Ce que le protocole ne prétend pas faire
Des limites explicites protègent le public et la crédibilité technique.
- Prédire les marchés ou garantir la performance d’une stratégie.
- Conserver des fonds, exécuter des ordres pour autrui ou automatiser le copy trading.
- Transformer une activité de membre en droit financier ou en influence achetée.
- Créer une nouvelle blockchain alors que des standards interopérables peuvent répondre au besoin.
Économie à deux instruments
Le paiement reste stable. SWTK sécurise le travail vérifiable.
Un abonnement ou une requête API n’a pas besoin d’un token volatil. Les stablecoins financent les services ; SWTK est conçu comme une caution portable et contestable entre vérificateurs, producteurs de preuves et challengers indépendants.
API, reçus et stockage
Stablecoin / paiement classique
Prix lisible et expérience simple.
Travail de vérification
Stablecoin
Rémunération d’un service mesurable.
Identité du vérificateur
Caution SWTK
Coût Sybil et responsabilité portable.
Affirmation ou contestation
Caution SWTK
Limiter le spam et exposer les fautes prouvables.
Token SWTK · en développement
SWTK est conçu comme la caution de sécurité du réseau Proof of Method.
Le lancement de SWTK fait partie de la feuille de route SwissTokint. Le token servira à engager la responsabilité économique des vérificateurs, des producteurs d’affirmations à haute assurance et des challengers. Son rôle n’est ni de remplacer les paiements stables, ni d’acheter la gouvernance de l’association, ni de promettre une performance financière.
01
Utilité observable
Un service en production, des utilisateurs externes et une raison mesurable pour laquelle un actif transférable améliore la sécurité ou l’accès.
02
Aucun droit financier
Ni dividende, ni partage de revenus, ni promesse de rachat, ni promesse de valeur. Le token ne peut pas devenir un substitut d’investissement.
03
Gouvernance séparée
Les votes de l’association restent « un membre éligible, une voix ». Détenir un token ne donne pas de pouvoir sur l’association.
04
Contrôles avant toute diffusion
Avis juridique par juridiction, analyse AML/sanctions, audit de contrat, politique de conflits d’intérêts et documentation de risque complète.
Spécification cible v0.3
Un actif de caution limité, auditable et distinct des frais de service.
Ces paramètres constituent le modèle de conception publié. Ils seront testés sur un réseau sans valeur avant le déploiement du contrat de production. Toute modification matérielle sera versionnée, justifiée et annoncée avant le lancement.
- Phase actuelle
- Conception active
- Fonction principale
- Caution de sécurité
- Réseau cible
- L2 EVM à confirmer
- Offre maximale proposée
- 1 000 000 000 SWTK
- Frais de service
- Stablecoins / monnaie
- Prévente communautaire
- 10 % maximum
- Objectif de financement
- CHF 750k–2,5 M
- Disponibilité publique
- Après contrôles
Protocole de reçus, SDK et modèle de caution en développement.
Verrouillage pour accepter une mission, publier une affirmation ou ouvrir une contestation.
Compatibilité recherchée avec EAS, ERC-8004, EIP-712 et ERC-1271.
Plafond de modélisation sans fonction de création discrétionnaire après déploiement.
L’accès à l’API ne force pas l’achat du token et reste tarifé dans une unité stable.
Jusqu’à 100 000 000 SWTK réservés au public selon des conditions encore soumises à validation.
Seuil minimal et plafond indicatifs, avec un objectif central de CHF 2 M ; aucun prix ou encaissement avant la documentation conforme.
Aucune date, adresse de contrat ou souscription avant validation sécurité et juridique.
Cycle économique
Verrouiller, vérifier, contester et régler selon des règles publiques.
01
Mandat borné
Une demande précise la preuve attendue, le délai, le niveau d’assurance et la caution minimale.
02
Caution verrouillée
Le vérificateur ou le demandeur verrouille SWTK dans un coffre non dépositaire pour la durée du mandat.
03
Attestation publiée
Le travail produit une attestation signée qui décrit exactement le contrôle réalisé et ses limites.
04
Fenêtre de contestation
Un challenger peut déposer une preuve contradictoire avec sa propre caution afin de limiter le spam.
05
Règlement traçable
La caution est restituée, récompensée ou pénalisée selon une faute objectivement documentée et une procédure d’appel.
Modèle de distribution provisoire
Une offre plafonnée qui réserve 10 % à une participation publique encadrée.
Le modèle ci-dessous sert à la planification économique. La prévente communautaire est proposée mais n’est pas ouverte : le prix, les pays éligibles, le mécanisme d’encaissement et les droits exacts seront publiés uniquement après validation juridique et sécurité.
38 %
Sécurité du réseau et vérification
Programme décroissant sur 10 ans
17 %
Écosystème, pilotes et biens publics
Jalons vérifiables sur 8 ans
15 %
Trésorerie protocole
8 ans avec délai initial de 24 mois
12 %
Contributeurs initiaux
4 ans avec cliff de 12 mois
8 %
Communauté et testnet
Preuves de contribution et contrôles anti-Sybil
10 %
Prévente communautaire publique
10 % au lancement puis 90 % linéaire sur 18 mois
Risques et contrôles
Le whitepaper publie aussi les scénarios d’échec.
Qualification réglementaire
Avis juridiques suisse et marchés cibles, analyse AML/sanctions, fiscalité et documentation séparée avant toute offre.
Faille de contrat ou de clés
Tests, fuzzing, audit externe, multisignature, timelock, plafonds de caution et procédure de pause documentée.
Collusion ou identités Sybil
Cautions par niveau, réputation portable, conflits déclarés, diversité des vérificateurs et rotation des mandats.
Contestations abusives
Caution du challenger, fenêtre limitée, preuves normalisées, décision motivée et voie d’appel.
Volatilité et liquidité
Frais libellés en stablecoins, caution plafonnée par mandat et absence de promesse de prix ou de rendement.
Fuite de données
Données sensibles hors chaîne, engagements salés, divulgation minimale et revue des métadonnées.
Feuille de route de lancement
Construire le réseau et ses contrôles avant de rendre SWTK transférable.
0–3 mois
Spécification, SDK et vérificateur
Une preuve locale reproductible, sans donnée sensible.
3–6 mois
Ancrage testnet et trois bots pilotes
50 000 reçus et coûts publiés.
6–9 mois
EAS, ERC-8004 et vérificateurs externes
100 revues et dix disputes synthétiques.
9–12 mois
API x402 et dossier réglementaire
Service mesurable, qualification juridique, whitepaper réglementaire et conditions de vente.
12–15 mois
Prévente communautaire encadrée
Entité émettrice, KYC/AML, restrictions géographiques, fonds protégés et seuil minimal documenté.
15–18 mois
Contrats SWTK, audit et testnet sans valeur
Cinq vérificateurs, exercices de contestation et rapport d’audit public.
18–24 mois
Lancement public contrôlé
Cadre juridique, sécurité, gouvernance, contrats et documentation de lancement validés.
Pistes et standards à évaluer
La recherche s’appuie sur des briques publiques plutôt que sur une chaîne propriétaire.
Ethereum Attestation Service
Une infrastructure open source et sans token dédiée aux attestations sur ou hors chaîne ; candidate pour l’interopérabilité du registre.
ERC-8004 — Trustless Agents
Un standard émergent pour l’identité, la réputation et les demandes de validation d’agents.
x402
Un protocole de paiement HTTP natif pour services et agents ; candidat pour les frais en stablecoins.
Agent2Agent Protocol
Un protocole ouvert permettant à des agents opaques de collaborer sans révéler leur état interne.
Forta Network
Un précédent de caution et pénalité pour des nœuds et bots fournissant un travail de sécurité.
Code de référence SwissTokint
Le noyau open source actuel de règles de risque reproductibles, publié sous licence MIT.