Jedes Jahr werden Milliarden von Dollar auf der Grundlage von Versprechen bewegt. Investoren verpflichten sich gegenüber Gründern. Gründer verpflichten sich zu Meilensteinen. Berater verpflichten sich zu Einführungen. Mitarbeiter verpflichten sich zu einem Vesting-Zeitplan.
Und jedes Jahr werden diese Versprechen gebrochen – nicht weil Menschen unehrlich sind, sondern weil Papiervereinbarungen statisch sind, die Durchsetzung teuer ist und die Nachverfolgung manuell erfolgt.
Tokenized Promise ändert das.
Das Problem mit traditionellen Vereinbarungen
Betrachten Sie einen typischen SAFE (Simple Agreement for Future Equity):
- Investor überweist Geld
- Gründer verspricht, Meilensteine zu erreichen
- Monate vergehen
- Haben sie die Meilensteine erreicht? Wer entscheidet das? Was passiert, wenn sie es nicht getan haben?
Die Antworten finden sich in E-Mails, Tabellenkalkulationen, vierteljährlichen Updates und schließlich – Anwälten.
Für Investoren: Keine automatische Nachverfolgung. Keine objektiven Auslöser. Streitigkeiten sind teuer und zerstören Beziehungen.
Für Gründer: Ständige Berichtspflicht. Die Besorgnis der Investoren erzeugt Reibungsverluste. Keine Möglichkeit, die Leistung objektiv nachzuweisen.
Für Berater: Beteiligungsversprechen, die sich nie materialisieren. Keine Hebelwirkung, wenn das Unternehmen das Handschlaggeschäft "vergisst".
Für Mitarbeiter: Vesting-Zeitpläne, die sich ändern. Cliff-Bestimmungen, die selektiv durchgesetzt werden. Exit-Ereignisse, die aus irgendeinem Grund nicht auslösen, was versprochen wurde.
Das Muster ist durchgängig: Zusagen werden gemacht, aber die Durchsetzung beruht auf Wohlwollen und teuren Gerichtsverfahren.
Was ist ein Tokenized Promise?
Ein Tokenized Promise ist eine programmierbare Zusage mit drei Kerneigenschaften:
- Definierte Bedingungen: Was löst das Versprechen aus (Meilenstein, Datum, Metrik)
- Automatische Überprüfung: Wie wir wissen, dass die Bedingung erfüllt wurde
- Ausführbares Ergebnis: Was passiert, wenn es ausgelöst wird (Zahlung, Freigabe von Eigenkapital usw.)
Anstatt "Ich verspreche, Ihnen 50.000 US-Dollar zu zahlen, wenn Sie 100.000 US-Dollar MRR erreichen", codiert ein Tokenized Promise:
IF mrr_verified >= 100000
AND verification_source IN [approved_oracles]
AND timestamp <= deadline
THEN release(funds, recipient, 50000)
ELSE IF timestamp > deadline
THEN return(funds, investor)
Die Logik ist explizit. Die Ausführung erfolgt automatisch. Der Audit-Trail ist dauerhaft.
Architektur: Zwei Wege, derselbe Standard
Wir bauen Tokenized Promise als einen offenen Standard, den jeder implementieren kann. Darüber hinaus bauen wir eine umfangreiche UX-Schicht, die ihn für nicht-technische Benutzer zugänglich macht.
Aber hier ist die wichtigste Erkenntnis: Nicht jeder will (oder kann) Blockchain-Infrastruktur nutzen. Die regulatorischen Anforderungen sind unterschiedlich. Die technischen Möglichkeiten sind unterschiedlich. Daher unterstützen wir zwei Bereitstellungsmodi:
Enterprise Mode (Managed Backend)
Für Organisationen, die Compliance, Auditierbarkeit und Kontrolle benötigen – ohne Blockchain-Komplexität.
// Enterprise Tokenized Promise - Server-side
interface EnterprisePromise {
id: string;
parties: {
promisor: Party; // Wer das Versprechen gibt
beneficiary: Party; // Wer es bei Erfüllung erhält
arbitrator?: Party; // Optionaler Streitschlichter
};
conditions: Condition[];
escrow: {
amount: number;
currency: string;
custodian: 'athanor' | 'bank' | 'custom';
};
verification: {
type: 'oracle' | 'attestation' | 'multi-sig';
sources: VerificationSource[];
threshold: number; // Wie viele Quellen müssen zustimmen
};
dispute: {
window: Duration; // Zeit, um Streit nach Auslösung zu erheben
resolution: 'arbitration' | 'mediation' | 'court';
jurisdiction: string;
};
compliance: {
kyc: boolean;
aml: boolean;
jurisdiction: string[];
reportingRequirements: Report[];
};
}
So funktioniert es:
- Parteien unterzeichnen die Vereinbarung (digitale Signaturen, rechtsverbindlich)
- Gelder werden in einem regulierten Treuhandkonto gehalten (Bankkonto oder lizenzierter Treuhänder)
- Athanor überwacht die Bedingungen über integrierte Datenquellen
- Wenn ausgelöst, werden Gelder automatisch verschoben (innerhalb der regulatorischen Rahmenbedingungen)
- Vollständiger Audit-Trail für die Compliance-Berichterstattung
Am besten geeignet für:
- Regulierte Unternehmen (Fonds, Family Offices)
- Grenzüberschreitende Geschäfte, die bestimmte Länder erfordern
- Organisationen mit Compliance-Anforderungen
- Deals, bei denen Gegenparteien keine Krypto-Infrastruktur haben
Self-Custody Mode (Smart Contracts)
Für diejenigen, die eine vertrauenslose Ausführung wünschen – kein Vermittler kann das Versprechen nach der Bereitstellung blockieren oder ändern.
// 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.
}
So funktioniert es:
- Promise on-chain mit codierten Bedingungen erstellt
- Gelder in Smart Contract gesperrt (kein Dritter kann darauf zugreifen)
- Zugelassene Orakel reichen Beweise ein, wenn die Bedingungen erfüllt sind
- Der Vertrag gibt automatisch Gelder frei, wenn der Schwellenwert erreicht ist
- Der Streitbeilegungsmechanismus ermöglicht eine Anfechtung innerhalb eines definierten Zeitfensters
Am besten geeignet für:
- Krypto-native Parteien
- Trustless Ausführungsanforderungen
- Globale Deals ohne länderspezifische Einschränkungen
- Maximale Transparenz und Auditierbarkeit
Die Verifizierungsschicht
Beide Modi verwenden dieselbe Verifizierungsarchitektur. Hier wird Tokenized Promise interessant.
Oracle-Typen
type OracleType =
| 'financial' // Umsatz, MRR, Burn Rate (über Accounting-Integrationen)
| 'product' // DAU, Retention, Feature-Launches (über Analytics)
| 'legal' // Incorporation, IP-Anmeldung, Compliance (über Legal APIs)
| 'human' // Expertenaussage, Genehmigung durch den Verwaltungsrat
| 'composite'; // Kombination aus obigem
interface Oracle {
id: string;
type: OracleType;
trustScore: number; // Historische Genauigkeit
attestationMethod: 'api' | 'signature' | 'multi-sig';
disputeHistory: Dispute[];
}
// Beispiel: MRR-Verifikationsorakel
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'
}
};
Multi-Source-Überprüfung
Für Promises mit hohen Einsätzen reicht eine Single-Source-Verifizierung nicht aus:
const milestoneVerification = {
condition: 'mrr_reaches_100k',
// Es müssen 2 von 3 Quellen übereinstimmen
threshold: 2,
sources: [
{ oracle: 'stripe-mrr-oracle', weight: 1 },
{ oracle: 'quickbooks-revenue', weight: 1 },
{ oracle: 'cfo-attestation', weight: 1 }
],
// Toleranz für geringfügige Abweichungen
tolerance: {
type: 'percentage',
value: 0.05 // 5% Varianz zulässig
},
// Was passiert bei Meinungsverschiedenheiten
disagreementResolution: 'arbitration'
};
Streitbeilegung: Das Sicherheitsnetz
Auch bei automatischer Überprüfung kommt es zu Streitigkeiten. Unser mehrschichtiges Schlichtungssystem regelt dies:
Ebene 1: Automatisierte Auflösung
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'
}
];
}
Ebene 2: Menschliche Schiedsgerichtsbarkeit
Wenn automatisierte Regeln nicht aufgelöst werden können:
interface ArbitrationProcess {
arbitrators: {
pool: 'athanor_certified' | 'jams' | 'custom';
selection: 'random' | 'mutual_agreement' | 'rotating';
count: 1 | 3 | 5; // Ungerade Anzahl für Mehrheit
};
process: {
submissionWindow: '7d';
responseWindow: '7d';
deliberationWindow: '14d';
appealable: boolean;
};
costs: {
filing: number;
arbitratorFee: number;
allocation: 'loser_pays' | 'split' | 'proportional';
};
}
Ebene 3: Rechtliche Eskalation
Für Fälle, die ein gerichtliches Eingreifen erfordern:
interface LegalEscalation {
jurisdiction: string;
governingLaw: string;
venue: string;
// Beweispaket automatisch generiert
evidenceBundle: {
originalAgreement: Document;
transactionHistory: Transaction[];
oracleAttestations: Attestation[];
communicationLog: Message[];
disputeRecord: DisputeRecord;
};
}
Anwendungsfälle in der realen Welt
1. Meilensteinbasierte Investition
Der Schmerz: Der Investor möchte in Tranchen finanzieren, die an Meilensteine gebunden sind. Derzeit erfordert dies eine manuelle Nachverfolgung, vierteljährliche Anrufe und das Vertrauen, dass der Gründer ehrlich berichtet.
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'
}
]
};
Ergebnis: Der Investor ist zuversichtlich, dass die Meilensteine objektiv verfolgt werden. Der Gründer hat klare Ziele mit automatischer Freigabe der Gelder. Keine vierteljährlichen Anrufe "Sind wir schon da?".
2. Beraterbeteiligung mit Biss
Der Schmerz: Dem Berater wurden 0,5 % für Einführungen versprochen. Das Unternehmen wächst und "vergisst" den Deal. Der Berater hat keine Hebelwirkung.
const advisorAgreement = {
equity: {
amount: 0.005, // 0.5%
type: 'options',
vestingSchedule: 'milestone'
},
milestones: [
{
description: '3 qualifizierte Investoreneinführungen',
verification: {
type: 'multi_attestation',
required: ['advisor', 'founder', 'investor']
},
equity_release: 0.002
},
{
description: 'Series A mit Intro-Investor abgeschlossen',
verification: {
type: 'legal_oracle',
document: 'series_a_closing_docs'
},
equity_release: 0.003
}
],
dispute: {
resolution: 'arbitration',
evidence: 'email_trail_required'
}
};
Ergebnis: Der Berater hat einen kryptografischen Beweis für die Vereinbarung. Meilensteine werden von mehreren Parteien überprüft. Kein "Er hat gesagt, sie hat gesagt".
3. Umsatzbeteiligungsvereinbarungen
Der Schmerz: Der Content-Ersteller hat einen Rev-Share-Deal mit der Plattform. Die Plattform berichtet, was immer sie will. Der Ersteller hat keine Prüfungsrechte.
const revenueShare = {
parties: {
creator: 'creator_wallet_or_account',
platform: 'platform_entity'
},
terms: {
percentage: 0.30, // 30% an den Ersteller
metric: 'net_revenue_from_content',
paymentFrequency: 'monthly'
},
verification: {
primary: 'platform_analytics_api',
secondary: 'third_party_audit_quarterly',
discrepancyThreshold: 0.10 // 10% lösen die Prüfung aus
},
payment: {
automatic: true,
currency: 'usd',
method: 'bank_transfer' // oder 'crypto' im Self-Custody-Modus
}
};
Ergebnis: Der Ersteller erhält automatische Zahlungen, die an verifizierte Metriken gebunden sind. Die Plattform kann nicht unterberichten. Streitigkeiten lösen eine automatische Prüfung aus.
4. Mitarbeiter-Vesting mit objektiven Auslösern
Der Schmerz: Der Mitarbeiter hat ein 4-Jahres-Vesting mit "Good Leaver"-Bestimmungen. Das Unternehmen entscheidet, was "gut" bedeutet, wenn es passt.
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' // Erfordert auch die Kündigung
},
{
trigger: 'termination_without_cause',
verification: ['hr_system', 'legal_review'],
acceleration: '6_months'
}
],
goodLeaver: {
definition: 'explicit', // Nicht "nach Ermessen des Vorstands"
conditions: [
'resignation_with_notice',
'termination_without_cause',
'disability',
'death'
],
verification: 'hr_oracle_plus_attestation'
}
};
Ergebnis: Der Mitarbeiter weiß genau, was was auslöst. Keine Überraschungen durch "Ermessen des Vorstands". Die Beschleunigung erfolgt automatisch, wenn die Bedingungen überprüft werden.
Integrierte Compliance
Tokenized Promise ist für die regulierte Welt konzipiert:
KYC/AML-Integration
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, // Für sicherheitsbezogene Promises
verification: 'verify_investor' | 'manual',
reVerification: '90_days'
}
};
Rechtsprechungsbewusste Ausführung
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']
}
};
Die Roadmap
2026: Formen und Validieren
In diesem Jahr geht es darum, das Fundament richtig zu legen:
- Q1-Q2: Start mit 2 Live-Tokenized Promises (echte Gegenparteien, echte Einsätze)
- Q2-Q3: Open-Source die Standardspezifikation
- Q3-Q4: Implementierung von Enterprise- und Self-Custody-Modi basierend auf dem Feedback von Early Adoptern
- Laufend: Iteration von Verifizierungs-Orakeln, Streitbeilegung, UX
Wir bauen nicht im luftleeren Raum. Jede Funktion wird ausgeliefert, weil ein echter Benutzer sie benötigt hat.
2027: Reifen und Skalieren
Im nächsten Jahr geht es um die Reichweite:
- Reifung des Oracle-Netzwerks (mehr Datenquellen, höhere Trust-Scores)
- Skalierung der Streitbeilegung (zertifiziertes Schiedsrichter-Netzwerk)
- Erweiterung der Gerichtsbarkeitsabdeckung
- Start des Marktplatzes für Tokenized-Promise-Vorlagen
- Aktivierung der Zusammensetzbarkeit (Promises, die andere Promises auslösen)
Der geschlossene Kreislauf
Hier ist die Vision: Jede Verpflichtung auf Athanor wird zu einem Tokenized Promise.
- Der Gründer reicht eine Idee ein → verpflichtet sich zu Meilensteinen über TP
- Investor finanziert → Tranchen werden über TP freigegeben
- Advisor tritt bei → Equity veste über TP
- Mitarbeiter eingestellt → Vesting wird über TP verfolgt
Jedes Promise verifiziert. Jedes Ergebnis verfolgt. Jeder Streitfall lösbar.
Nicht, weil wir den Menschen nicht vertrauen – sondern weil klare Verpflichtungen das Vertrauen erleichtern.
Beteiligen Sie sich
Wir suchen aktiv nach:
Early Adopters: Investoren und Gründer, die bereit sind, echte Deals als Tokenized Promises zu strukturieren. Wir arbeiten eng mit Ihnen bei der Implementierung zusammen.
Rechtspartner: Kanzleien, die daran interessiert sind, länderspezifische Vorlagen und Gutachten zu entwickeln.
Technische Mitwirkende: Der Standard wird Open-Source sein. Helfen Sie uns, es richtig zu bauen.
Feedback: Auch wenn Sie noch nicht bereit sind, es zu verwenden, sagen Sie uns, was dies für Ihren Workflow wertvoll machen würde.
Sind Sie bereit, Tokenized Promise für Ihren nächsten Deal zu erkunden? Lass uns reden.
