Щороку мільярди доларів переміщуються на основі обіцянок. Інвестор зобов'язується перед засновником. Засновник зобов'язується досягти етапів. Радник зобов'язується надавати знайомства. Співробітник зобов'язується дотримуватися графіка розблокування.
І щороку ці обіцянки порушуються — не тому, що люди нечесні, а тому, що паперові угоди статичні, забезпечення їх виконання є дорогим, а відстеження — ручним.
Tokenized Promise змінює це.
Проблема з Традиційними Угодами
Розглянемо типовий SAFE (Simple Agreement for Future Equity):
- Інвестор переказує гроші
- Засновник обіцяє досягти етапів
- Минають місяці
- Чи досягли вони етапів? Хто вирішує? Що станеться, якщо ні?
Відповіді містяться в електронних листах, електронних таблицях, щоквартальних звітах і, зрештою, — у юристів.
Для інвесторів: Без автоматичного відстеження. Без об'єктивних тригерів. Спори є дорогими та руйнують відносини.
Для засновників: Постійний тягар звітності. Тривога інвесторів створює тертя. Немає можливості об'єктивно довести виконання.
Для радників: Обіцянки щодо акцій, які ніколи не матеріалізуються. Відсутність впливу, коли компанія "забуває" про угоду потиску руки.
Для співробітників: Графіки розблокування, які змінюються. Положення про відтермінування, які застосовуються вибірково. Події виходу, які якимось чином не запускають те, що було обіцяно.
Закономірність є послідовною: беруться зобов'язання, але виконання залежить від доброї волі та дорогих судових позовів.
Що Таке Tokenized Promise?
Tokenized Promise — це програмоване зобов'язання з трьома основними властивостями:
- Визначені умови: Що запускає обіцянку (етап, дата, показник)
- Автоматична перевірка: Як ми дізнаємося, що умова виконана
- Виконуваний результат: Що відбувається після запуску (оплата, випуск акцій тощо)
Замість "Я обіцяю заплатити вам 50 тис. доларів, коли ви досягнете 100 тис. доларів MRR", 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)
Логіка є явною. Виконання є автоматичним. Аудиторський слід є постійним.
Архітектура: Два Шляхи, Один Стандарт
Ми створюємо Tokenized Promise як відкритий стандарт, який кожен може реалізувати. Крім того, ми створюємо багатий UX-шар, який робить його доступним для нетехнічних користувачів.
Але ось головне: не всі хочуть (або можуть використовувати) інфраструктуру блокчейну. Нормативні вимоги різняться. Технічні можливості відрізняються. Тому ми підтримуємо два режими розгортання:
Enterprise Mode (Керований Бекенд)
Для організацій, яким потрібні відповідність, можливість перевірки та контроль — без складності блокчейну.
// Enterprise Tokenized Promise - Server-side
interface EnterprisePromise {
id: string;
parties: {
promisor: Party; // Хто дає обіцянку
beneficiary: Party; // Хто отримує, якщо виконано
arbitrator?: Party; // Додатковий арбітр для вирішення спорів
};
conditions: Condition[];
escrow: {
amount: number;
currency: string;
custodian: 'athanor' | 'bank' | 'custom';
};
verification: {
type: 'oracle' | 'attestation' | 'multi-sig';
sources: VerificationSource[];
threshold: number; // Скільки джерел має погодитися
};
dispute: {
window: Duration; // Час для порушення спору після запуску
resolution: 'arbitration' | 'mediation' | 'court';
jurisdiction: string;
};
compliance: {
kyc: boolean;
aml: boolean;
jurisdiction: string[];
reportingRequirements: Report[];
};
}
Як це працює:
- Сторони підписують угоду (цифрові підписи, юридично обов'язкові)
- Кошти зберігаються на регульованому депозитному рахунку (банківський рахунок або ліцензований зберігач)
- Athanor відстежує умови за допомогою інтегрованих джерел даних
- Після запуску кошти переміщуються автоматично (в рамках нормативних вимог)
- Повний аудит для звітності про відповідність
Найкраще для:
- Регульованих організацій (фондів, сімейних офісів)
- Транскордонних угод, що вимагають певних юрисдикцій
- Організацій з вимогами відповідності
- Угод, де контрагенти не мають крипто інфраструктури
Self-Custody Mode (Смарт-Контракти)
Для тих, хто хоче надійного виконання — жоден посередник не може заблокувати або змінити обіцянку після розгортання.
// 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.
}
Як це працює:
- Обіцянка створюється в ланцюжку з закодованими умовами
- Кошти заблоковані в смарт-контракті (жодна третя сторона не може отримати доступ)
- Затверджені оракули подають докази, коли умови виконані
- Контракт автоматично вивільняє кошти, коли досягнуто поріг
- Механізм врегулювання спорів дозволяє оскаржити протягом визначеного періоду
Найкраще для:
- Крипто-властивих сторін
- Вимог надійного виконання
- Глобальних угод без юрисдикційних обмежень
- Максимальної прозорості та можливості перевірки
Шар Перевірки
Обидва режими мають однакову архітектуру перевірки. Ось де Tokenized Promise стає цікавим.
Типи Оракулів
type OracleType =
| 'financial' // Дохід, MRR, коефіцієнт вигорання (через інтеграції бухгалтерського обліку)
| 'product' // DAU, утримання, запуски функцій (через аналітику)
| 'legal' // Інкорпорація, подання IP, відповідність (через юридичні API)
| 'human' // Атестація експертів, схвалення ради
| 'composite'; // Комбінація вищевказаного
interface Oracle {
id: string;
type: OracleType;
trustScore: number; // Історична точність
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'
}
};
Багатоджерельна Перевірка
Для обіцянок із високими ставками однієї джерела перевірки недостатньо:
const milestoneVerification = {
condition: 'mrr_reaches_100k',
// Потрібно, щоб 2 з 3 джерел погодилися
threshold: 2,
sources: [
{ oracle: 'stripe-mrr-oracle', weight: 1 },
{ oracle: 'quickbooks-revenue', weight: 1 },
{ oracle: 'cfo-attestation', weight: 1 }
],
// Допуск на незначні розбіжності
tolerance: {
type: 'percentage',
value: 0.05 // Допускається відхилення 5%
},
// Що відбувається при розбіжностях
disagreementResolution: 'arbitration'
};
Вирішення Спорів: Мережа Безпеки
Навіть за наявності автоматичної перевірки виникають спори. Наша багаторівнева система вирішення справляється з ними:
Рівень 1: Автоматизоване Розв'язання
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'
}
];
}
Рівень 2: Людський Третейський Суд
Коли автоматизовані правила не можуть вирішити:
interface ArbitrationProcess {
arbitrators: {
pool: 'athanor_certified' | 'jams' | 'custom';
selection: 'random' | 'mutual_agreement' | 'rotating';
count: 1 | 3 | 5; // Непарна кількість для більшості
};
process: {
submissionWindow: '7d';
responseWindow: '7d';
deliberationWindow: '14d';
appealable: boolean;
};
costs: {
filing: number;
arbitratorFee: number;
allocation: 'loser_pays' | 'split' | 'proportional';
};
}
Рівень 3: Юридична Ескалація
Для випадків, які вимагають судового втручання:
interface LegalEscalation {
jurisdiction: string;
governingLaw: string;
venue: string;
// Пакет доказів генерується автоматично
evidenceBundle: {
originalAgreement: Document;
transactionHistory: Transaction[];
oracleAttestations: Attestation[];
communicationLog: Message[];
disputeRecord: DisputeRecord;
};
}
Випадки Використання в Реальному Світі
1. Інвестиції на Основі Віх
Біль: Інвестор хоче фінансувати траншами, прив’язаними до віх. На даний момент потрібне ручне відстеження, щоквартальні дзвінки та довіра до того, що засновник чесно звітуватиме.
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'
}
]
};
Результат: Інвестор впевнений, що віхи відстежуються об’єктивно. Засновник має чіткі цілі з автоматичним вивільненням коштів. Ніяких щоквартальних дзвінків "ми вже там?".
2. Капітал Порадника з Зубами
Біль: Раднику обіцяли 0,5% за знайомства. Компанія росте, "забуває" про угоду, радник не має впливу.
const advisorAgreement = {
equity: {
amount: 0.005, // 0.5%
type: 'options',
vestingSchedule: 'milestone'
},
milestones: [
{
description: '3 qualified investor intros',
verification: {
type: 'multi_attestation',
required: ['advisor', 'founder', 'investor']
},
equity_release: 0.002
},
{
description: 'Series A closed with intro investor',
verification: {
type: 'legal_oracle',
document: 'series_a_closing_docs'
},
equity_release: 0.003
}
],
dispute: {
resolution: 'arbitration',
evidence: 'email_trail_required'
}
};
Результат: Радник має криптографічний доказ угоди. Віхи перевіряються кількома сторонами. Ніяких "він сказав, вона сказала".
3. Угоди Про Розподіл Доходів
Біль: Творець контенту має угоду про розподіл доходів з платформою. Платформа повідомляє про все, що захоче. Творець не має прав на аудит.
const revenueShare = {
parties: {
creator: 'creator_wallet_or_account',
platform: 'platform_entity'
},
terms: {
percentage: 0.30, // 30% творцю
metric: 'net_revenue_from_content',
paymentFrequency: 'monthly'
},
verification: {
primary: 'platform_analytics_api',
secondary: 'third_party_audit_quarterly',
discrepancyThreshold: 0.10 // Розбіжність 10% запускає аудит
},
payment: {
automatic: true,
currency: 'usd',
method: 'bank_transfer' // or 'crypto' in self-custody mode
}
};
Результат: Творець отримує автоматичні платежі, прив’язані до перевірених показників. Платформа не може занижувати звітність. Спори запускають автоматичний аудит.
4. Розблокування Акцій Працівників із Об’єктивними Тригерами
Біль: Працівник має розблокування на 4 роки з положеннями про "хорошого лівера". Компанія вирішує, що означає "хороший", коли це зручно.
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' // Вимагає також припинення дії
},
{
trigger: 'termination_without_cause',
verification: ['hr_system', 'legal_review'],
acceleration: '6_months'
}
],
goodLeaver: {
definition: 'explicit', // Не "на розсуд правління"
conditions: [
'resignation_with_notice',
'termination_without_cause',
'disability',
'death'
],
verification: 'hr_oracle_plus_attestation'
}
};
Результат: Працівник точно знає, що що запускає. Ніяких несподіванок від "розсуду правління". Прискорення є автоматичним, коли умови перевірені.
Вбудована Відповідність
Tokenized Promise розроблено для регульованого світу:
Інтеграція 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, // Для обіцянок, пов'язаних з цінними паперами
verification: 'verify_investor' | 'manual',
reVerification: '90_days'
}
};
Виконання з Урахуванням Юрисдикції
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']
}
};
Дорожня Карта
2026: Формування та Валідація
Цей рік призначений для правильної підготовки основи:
- I-II кв: Запуск із 2-ма активними Tokenized Promise (реальні контрагенти, реальні ставки)
- II-III кв: Відкритий код стандартної специфікації
- III-IV кв: Реалізація корпоративного режиму та режиму самостійного зберігання на основі відгуків ранніх користувачів
- Постійно: Ітерація на оракулах перевірки, вирішенні спорів, UX
Ми не будуємо у вакуумі. Кожна функція надходить, оскільки вона була потрібна реальному користувачеві.
2027: Зрілість і Масштаб
Наступний рік — рік досягнення:
- Розвивати мережу оракулів (більше джерел даних, вищі показники довіри)
- Масштабувати вирішення спорів (сертифікована мережа арбітрів)
- Розширити охоплення юрисдикції
- Запуск торгівельного майданчика для шаблонів Tokenized Promise
- Надання можливості компонування (обіцянки, які викликають інші обіцянки)
Замкнений Цикл
Ось бачення: кожне зобов'язання на Athanor стає Tokenized Promise.
- Засновник подає ідею → бере на себе зобов'язання щодо віх через TP
- Інвестор фінансує → транші вивільняються через TP
- Радник приєднується → капітал передається через TP
- Працівник найнятий → розблокування відстежується через TP
Кожна обіцянка перевіряється. Кожен результат відстежується. Кожен спір можна вирішити.
Не тому, що ми не довіряємо людям, а тому, що чіткі зобов'язання полегшують довіру.
Приєднатися
Ми активно шукаємо:
Ранні користувачі: Інвестори та засновники, які бажають структурувати реальні угоди як Tokenized Promise. Ми будемо тісно співпрацювати з вами над впровадженням.
Юридичні партнери: Фірми, зацікавлені в розробці шаблонів і висновків, специфічних для юрисдикції.
Технічні учасники: Стандартний буде з відкритим вихідним кодом. Допоможіть нам створити його правильно.
Відгуки: Навіть якщо ви не готові використовувати його, розкажіть, що зробило б його цінним для вашого робочого процесу.
Готові вивчити Tokenized Promise для вашої наступної угоди? Давайте поговоримо.
