Chaque année, des milliards de dollars sont transférés sur la base de promesses. Un investisseur s'engage envers un fondateur. Un fondateur s'engage à atteindre des étapes. Un conseiller s'engage à faire des présentations. Un employé s'engage à respecter un calendrier d'acquisition.
Et chaque année, ces promesses sont rompues, non pas parce que les gens sont malhonnêtes, mais parce que les accords papier sont statiques, l'application est coûteuse et le suivi est manuel.
Tokenized Promise change cela.
Le problème des accords traditionnels
Prenons l'exemple d'un SAFE (Simple Agreement for Future Equity) typique :
- L'investisseur vire de l'argent
- Le fondateur promet d'atteindre des étapes
- Les mois passent
- Ont-ils atteint les étapes ? Qui décide ? Que se passe-t-il s'ils ne l'ont pas fait ?
Les réponses se trouvent dans les courriels, les feuilles de calcul, les mises à jour trimestrielles et, finalement, les avocats.
Pour les investisseurs : Pas de suivi automatique. Pas de déclencheurs objectifs. Les litiges sont coûteux et détruisent les relations.
Pour les fondateurs : Charge de reporting constante. L'anxiété des investisseurs crée des frictions. Pas de moyen de prouver objectivement la performance.
Pour les conseillers : Promesses d'actions qui ne se matérialisent jamais. Pas de levier lorsque l'entreprise "oublie" l'accord de poignée de main.
Pour les employés : Calendriers d'acquisition qui changent. Dispositions de "cliff" appliquées sélectivement. Événements de sortie qui, d'une manière ou d'une autre, ne déclenchent pas ce qui avait été promis.
Le schéma est cohérent : des engagements sont pris, mais leur application repose sur la bonne volonté et des actions judiciaires coûteuses.
Qu'est-ce qu'une Tokenized Promise ?
Une Tokenized Promise est un engagement programmable avec trois propriétés essentielles :
- Conditions définies : Ce qui déclenche la promesse (étape, date, mesure)
- Vérification automatique : Comment nous savons que la condition a été remplie
- Résultat exécutable : Ce qui se passe lorsque la promesse est déclenchée (paiement, libération d'actions, etc.)
Au lieu de "Je promets de vous payer 50 000 dollars lorsque vous atteindrez 100 000 dollars de MRR", une Tokenized Promise encode :
SI mrr_verified >= 100000
ET verification_source DANS [approved_oracles]
ET timestamp <= deadline
ALORS release(funds, recipient, 50000)
SINON SI timestamp > deadline
ALORS return(funds, investor)
La logique est explicite. L'exécution est automatique. La piste d'audit est permanente.
Architecture : Deux voies, une même norme
Nous construisons Tokenized Promise en tant que standard ouvert que chacun peut mettre en œuvre. En plus de cela, nous créons une riche couche UX qui la rend accessible aux utilisateurs non techniques.
Mais voici l'idée clé : tout le monde ne veut ou ne peut pas utiliser l'infrastructure blockchain. Les exigences réglementaires varient. Les capacités techniques diffèrent. Nous prenons donc en charge deux modes de déploiement :
Mode Entreprise (Backend Géré)
Pour les organisations qui ont besoin de conformité, d'auditabilité et de contrôle, sans la complexité de la blockchain.
// Enterprise Tokenized Promise - Server-side
interface EnterprisePromise {
id: string;
parties: {
promisor: Party; // Qui fait la promesse
beneficiary: Party; // Qui reçoit si elle est honorée
arbitrator?: Party; // Résolveur de litiges facultatif
};
conditions: Condition[];
escrow: {
amount: number;
currency: string;
custodian: 'athanor' | 'bank' | 'custom';
};
verification: {
type: 'oracle' | 'attestation' | 'multi-sig';
sources: VerificationSource[];
threshold: number; // Combien de sources doivent être d'accord
};
dispute: {
window: Duration; // Délai pour soulever un litige après le déclenchement
resolution: 'arbitration' | 'mediation' | 'court';
jurisdiction: string;
};
compliance: {
kyc: boolean;
aml: boolean;
jurisdiction: string[];
reportingRequirements: Report[];
};
}
Comment ça marche :
- Les parties signent un accord (signatures numériques, juridiquement contraignant)
- Les fonds sont détenus en séquestre réglementé (compte bancaire ou dépositaire agréé)
- Athanor surveille les conditions via des sources de données intégrées
- Une fois déclenchés, les fonds sont transférés automatiquement (dans le cadre des réglementations)
- Piste d'audit complète pour les rapports de conformité
Idéal pour :
- Entités réglementées (fonds, family offices)
- Accords transfrontaliers nécessitant des juridictions spécifiques
- Organisations ayant des exigences de conformité
- Accords où les contreparties n'ont pas d'infrastructure crypto
Mode Auto-Custodie (Smart Contracts)
Pour ceux qui veulent une exécution sans confiance, aucun intermédiaire ne peut bloquer ou modifier la promesse une fois déployée.
// Self-Custody Tokenized Promise - Solidity
contract TokenizedPromise {
struct Promise {
address promisor;
address beneficiary;
uint256 amount;
bytes32 conditionHash;
uint256 deadline;
PromiseState state;
}
enum PromiseState {
Active,
Fulfilled,
Expired,
Disputed
}
mapping(bytes32 => Promise) public promises;
mapping(bytes32 => address[]) public oracles;
event PromiseCreated(bytes32 indexed id, address promisor, address beneficiary);
event ConditionMet(bytes32 indexed id, address oracle, bytes proof);
event PromiseFulfilled(bytes32 indexed id, uint256 amount);
event DisputeRaised(bytes32 indexed id, address challenger, string reason);
function createPromise(
address _beneficiary,
bytes32 _conditionHash,
uint256 _deadline,
address[] calldata _oracles
) external payable returns (bytes32) {
bytes32 id = keccak256(abi.encodePacked(
msg.sender,
_beneficiary,
_conditionHash,
block.timestamp
));
promises[id] = Promise({
promisor: msg.sender,
beneficiary: _beneficiary,
amount: msg.value,
conditionHash: _conditionHash,
deadline: _deadline,
state: PromiseState.Active
});
oracles[id] = _oracles;
emit PromiseCreated(id, msg.sender, _beneficiary);
return id;
}
function submitProof(
bytes32 _promiseId,
bytes calldata _proof
) external {
Promise storage p = promises[_promiseId];
require(p.state == PromiseState.Active, "Promise not active");
require(isApprovedOracle(_promiseId, msg.sender), "Not approved oracle");
require(block.timestamp <= p.deadline, "Past deadline");
// Verify proof matches condition
require(verifyCondition(p.conditionHash, _proof), "Invalid proof");
emit ConditionMet(_promiseId, msg.sender, _proof);
// Check if threshold met for release
if (oracleThresholdMet(_promiseId)) {
_fulfillPromise(_promiseId);
}
}
function _fulfillPromise(bytes32 _promiseId) internal {
Promise storage p = promises[_promiseId];
p.state = PromiseState.Fulfilled;
(bool sent, ) = p.beneficiary.call{value: p.amount}("");
require(sent, "Transfer failed");
emit PromiseFulfilled(_promiseId, p.amount);
}
// ... dispute resolution, expiry handling, etc.
}
Comment ça marche :
- La promesse est créée sur la chaîne avec les conditions encodées
- Les fonds sont bloqués dans un smart contract (aucun tiers ne peut y accéder)
- Les oracles approuvés soumettent des preuves lorsque les conditions sont remplies
- Le contrat libère automatiquement les fonds lorsque le seuil est atteint
- Un mécanisme de règlement des litiges permet de contester dans un délai défini
Idéal pour :
- Les parties natives de la crypto
- Les exigences d'exécution sans confiance
- Les accords mondiaux sans contraintes juridictionnelles
- Transparence et auditabilité maximales
La couche de vérification
Les deux modes partagent la même architecture de vérification. C'est là que Tokenized Promise devient intéressant.
Types d'Oracle
type OracleType =
| 'financial' // Revenus, MRR, taux de consommation (via les intégrations comptables)
| 'product' // DAU, rétention, lancements de fonctionnalités (via l'analyse)
| 'legal' // Incorporation, dépôt de PI, conformité (via les API juridiques)
| 'human' // Attestation d'expert, approbation du conseil
| 'composite'; // Combinaison de ce qui précède
interface Oracle {
id: string;
type: OracleType;
trustScore: number; // Précision historique
attestationMethod: 'api' | 'signature' | 'multi-sig';
disputeHistory: Dispute[];
}
// Example: MRR verification oracle
const mrrOracle: Oracle = {
id: 'stripe-mrr-oracle',
type: 'financial',
trustScore: 0.99,
attestationMethod: 'api',
dataSource: {
provider: 'stripe',
endpoint: '/v1/subscription_metrics',
authentication: 'oauth',
refreshInterval: '24h'
}
};
Vérification Multi-Source
Pour les promesses à enjeux élevés, une vérification à source unique ne suffit pas :
const milestoneVerification = {
condition: 'mrr_reaches_100k',
// Exiger que 2 des 3 sources soient d'accord
threshold: 2,
sources: [
{ oracle: 'stripe-mrr-oracle', weight: 1 },
{ oracle: 'quickbooks-revenue', weight: 1 },
{ oracle: 'cfo-attestation', weight: 1 }
],
// Tolérance pour les écarts mineurs
tolerance: {
type: 'percentage',
value: 0.05 // 5% de variance autorisée
},
// Ce qui se passe en cas de désaccord
disagreementResolution: 'arbitration'
};
Résolution des litiges : le filet de sécurité
Même avec une vérification automatique, des litiges surviennent. Notre système de résolution à plusieurs niveaux s'en occupe :
Niveau 1 : Résolution Automatisée
interface AutomatedResolution {
trigger: 'oracle_disagreement' | 'deadline_ambiguity' | 'partial_fulfillment';
rules: [
{
condition: 'variance < tolerance',
action: 'accept_median_value'
},
{
condition: 'one_oracle_offline',
action: 'extend_deadline_24h'
},
{
condition: 'partial_fulfillment > 80%',
action: 'release_proportional'
}
];
}
Niveau 2 : Arbitrage Humain
Lorsque les règles automatisées ne peuvent pas résoudre le problème :
interface ArbitrationProcess {
arbitrators: {
pool: 'athanor_certified' | 'jams' | 'custom';
selection: 'random' | 'mutual_agreement' | 'rotating';
count: 1 | 3 | 5; // Nombre impair pour la majorité
};
process: {
submissionWindow: '7d';
responseWindow: '7d';
deliberationWindow: '14d';
appealable: boolean;
};
costs: {
filing: number;
arbitratorFee: number;
allocation: 'loser_pays' | 'split' | 'proportional';
};
}
Niveau 3 : Escalade Juridique
Pour les cas qui nécessitent une intervention du tribunal :
interface LegalEscalation {
jurisdiction: string;
governingLaw: string;
venue: string;
// Ensemble de preuves généré automatiquement
evidenceBundle: {
originalAgreement: Document;
transactionHistory: Transaction[];
oracleAttestations: Attestation[];
communicationLog: Message[];
disputeRecord: DisputeRecord;
};
}
Cas d'utilisation réels
1. Investissement Basé sur des Étapes
La douleur: L'investisseur veut financer par tranches liées à des étapes. Actuellement, cela nécessite un suivi manuel, des appels trimestriels et la confiance que le fondateur fera un rapport honnête.
const seriesAMilestones = {
totalCommitment: 2_000_000,
tranches: [
{
amount: 500_000,
condition: 'signing',
verification: 'legal_oracle'
},
{
amount: 500_000,
condition: 'mrr >= 50000',
verification: ['stripe_oracle', 'cfo_attestation'],
deadline: '2026-06-30'
},
{
amount: 500_000,
condition: 'team_size >= 10 AND product_launched',
verification: ['hr_oracle', 'product_oracle'],
deadline: '2026-12-31'
},
{
amount: 500_000,
condition: 'mrr >= 200000',
verification: ['stripe_oracle', 'auditor_attestation'],
deadline: '2027-06-30'
}
]
};
Résultat: L'investisseur est confiant que les étapes sont suivies objectivement. Le fondateur a des objectifs clairs avec une libération automatique des fonds. Pas d'appels trimestriels "on y est bientôt ?".
2. Actions de Conseiller avec les Moyens de Ses Ambitions
La douleur: Un conseiller s'est vu promettre 0,5 % pour des présentations. L'entreprise grandit, "oublie" l'accord, le conseiller n'a aucun pouvoir.
const advisorAgreement = {
equity: {
amount: 0.005, // 0.5%
type: 'options',
vestingSchedule: 'milestone'
},
milestones: [
{
description: '3 introductions d'investisseurs qualifiés',
verification: {
type: 'multi_attestation',
required: ['advisor', 'founder', 'investor']
},
equity_release: 0.002
},
{
description: 'Clôture du tour de série A avec un investisseur introduit',
verification: {
type: 'legal_oracle',
document: 'series_a_closing_docs'
},
equity_release: 0.003
}
],
dispute: {
resolution: 'arbitration',
evidence: 'email_trail_required'
}
};
Résultat: Le conseiller a une preuve cryptographique de l'accord. Les étapes sont vérifiées par plusieurs parties. Pas de "il a dit, elle a dit".
3. Accords de Partage des Revenus
La douleur: Un créateur de contenu a un accord de partage des revenus avec une plateforme. La plateforme rapporte ce qu'elle veut. Le créateur n'a pas le droit de réaliser des audits.
const revenueShare = {
parties: {
creator: 'creator_wallet_or_account',
platform: 'platform_entity'
},
terms: {
percentage: 0.30, // 30% au créateur
metric: 'net_revenue_from_content',
paymentFrequency: 'monthly'
},
verification: {
primary: 'platform_analytics_api',
secondary: 'third_party_audit_quarterly',
discrepancyThreshold: 0.10 // 10% déclenche un audit
},
payment: {
automatic: true,
currency: 'usd',
method: 'bank_transfer' // ou 'crypto' en mode auto-custodie
}
};
Résultat: Le créateur reçoit des paiements automatiques liés à des indicateurs vérifiés. La plateforme ne peut pas sous-estimer les revenus. Les litiges déclenchent un audit automatique.
4. Acquisition d'Actions d'Employés avec des Déclencheurs Objectifs
La douleur: L'employé a une acquisition d'actions sur 4 ans avec des dispositions de "bon départ". L'entreprise décide de ce que "bon" signifie quand cela lui convient.
const vestingSchedule = {
grant: {
shares: 10000,
type: 'iso',
grantDate: '2026-01-15'
},
vesting: {
cliff: '1y',
schedule: 'monthly_after_cliff',
totalPeriod: '4y'
},
acceleration: [
{
trigger: 'acquisition',
verification: 'legal_oracle',
acceleration: 'double_trigger' // Nécessite également une résiliation
},
{
trigger: 'termination_without_cause',
verification: ['hr_system', 'legal_review'],
acceleration: '6_months'
}
],
goodLeaver: {
definition: 'explicit', // Pas "à la discrétion du conseil"
conditions: [
'resignation_with_notice',
'termination_without_cause',
'disability',
'death'
],
verification: 'hr_oracle_plus_attestation'
}
};
Résultat: L'employé sait exactement ce qui déclenche quoi. Pas de surprises "à la discrétion du conseil". L'accélération est automatique lorsque les conditions sont vérifiées.
Conformité Intégrée
Tokenized Promise est conçu pour le monde réglementé :
Intégration KYC/AML
const complianceLayer = {
kyc: {
required: true,
provider: 'jumio' | 'onfido' | 'custom',
level: 'basic' | 'enhanced',
reVerification: '12_months'
},
aml: {
screening: 'chainalysis' | 'elliptic' | 'custom',
ongoingMonitoring: true,
thresholdReporting: {
amount: 10000,
currency: 'usd',
reportTo: ['fincen', 'local_regulator']
}
},
accreditation: {
required: true, // Pour les promesses liées aux titres
verification: 'verify_investor' | 'manual',
reVerification: '90_days'
}
};
Exécution Tenant Compte de la Juridiction
const jurisdictionRules = {
'US': {
securitiesLaw: 'reg_d_506c',
escrowRequirements: 'qualified_custodian',
reportingRequirements: ['form_d', 'blue_sky']
},
'EU': {
securitiesLaw: 'mifid_ii',
escrowRequirements: 'emi_or_bank',
reportingRequirements: ['esma_reporting']
},
'CRYPTO_NATIVE': {
securitiesLaw: 'token_not_security_opinion',
escrowRequirements: 'smart_contract',
reportingRequirements: ['on_chain_transparency']
}
};
La Feuille de Route
2026 : Former et Valider
Cette année est axée sur la mise en place d'une base solide :
- T1-T2: Lancement avec 2 Tokenized Promises en direct (contreparties réelles, enjeux réels)
- T2-T3: Open-source de la spécification standard
- T3-T4: Mise en œuvre des modes entreprise et auto-custodie en fonction des commentaires des premiers utilisateurs
- En cours: Itérer sur les oracles de vérification, le règlement des litiges, l'UX
Nous ne construisons pas dans le vide. Chaque fonctionnalité est livrée parce qu'un utilisateur réel en a besoin.
2027 : Mûrir et Déployer à Grande Échelle
L'année prochaine est axée sur la portée :
- Faire mûrir le réseau d'oracles (plus de sources de données, des scores de confiance plus élevés)
- Déployer à grande échelle le règlement des litiges (réseau d'arbitres certifiés)
- Étendre la couverture juridictionnelle
- Lancer une place de marché pour les modèles de Tokenized Promise
- Activer la composabilité (les promesses qui déclenchent d'autres promesses)
La Boucle Fermée
Voici la vision : chaque engagement sur Athanor devient une Tokenized Promise.
- Le fondateur soumet une idée → s'engage à atteindre des étapes via TP
- L'investisseur finance → les tranches sont libérées via TP
- Le conseiller rejoint → l'acquisition d'actions s'effectue via TP
- L'employé est embauché → l'acquisition est suivie via TP
Chaque promesse est vérifiée. Chaque résultat est suivi. Chaque litige peut être résolu.
Non pas parce que nous ne faisons pas confiance aux gens, mais parce que des engagements clairs facilitent la confiance.
Impliquez-vous
Nous recherchons activement :
Premiers utilisateurs: Investisseurs et fondateurs désireux de structurer des accords réels en tant que Tokenized Promises. Nous travaillerons en étroite collaboration avec vous sur la mise en œuvre.
Partenaires juridiques: Cabinets intéressés à élaborer des modèles et des avis spécifiques à la juridiction.
Contributeurs techniques: La norme sera open-source. Aidez-nous à bien la construire.
Commentaires: Même si vous n'êtes pas prêt à l'utiliser, dites-nous ce qui rendrait cela précieux pour votre flux de travail.
Prêt à explorer Tokenized Promise pour votre prochain accord ? Parlons-en.
