Cada año, miles de millones de dólares se mueven basados en promesas. El inversor se compromete con el fundador. El fundador se compromete con los hitos. El asesor se compromete con las presentaciones. El empleado se compromete con el calendario de adquisición de derechos.
Y cada año, esas promesas se rompen, no porque la gente sea deshonesta, sino porque los acuerdos en papel son estáticos, la aplicación es costosa y el seguimiento es manual.
Tokenized Promise cambia esto.
El problema con los acuerdos tradicionales
Considere un SAFE (Simple Agreement for Future Equity) típico:
- El inversor transfiere dinero
- El fundador promete alcanzar hitos
- Pasan los meses
- ¿Alcanzaron los hitos? ¿Quién decide? ¿Qué pasa si no lo hicieron?
Las respuestas viven en correos electrónicos, hojas de cálculo, actualizaciones trimestrales y, finalmente, abogados.
Para los inversores: No hay seguimiento automático. No hay desencadenantes objetivos. Las disputas son costosas y destructivas para las relaciones.
Para los fundadores: Carga constante de informes. La ansiedad de los inversores crea fricción. No hay forma de probar el rendimiento objetivamente.
Para los asesores: Promesas de capital que nunca se materializan. No hay influencia cuando la empresa "olvida" el trato de palabra.
Para los empleados: Calendarios de adquisición de derechos que cambian. Cláusulas de cliff aplicadas selectivamente. Eventos de salida que de alguna manera no desencadenan lo que se prometió.
El patrón es consistente: se asumen compromisos, pero la aplicación depende de la buena voluntad y de costosas acciones legales.
¿Qué es una Tokenized Promise?
Una Tokenized Promise es un compromiso programable con tres propiedades fundamentales:
- Condiciones definidas: Qué desencadena la promesa (hito, fecha, métrica)
- Verificación automática: Cómo sabemos que se cumplió la condición
- Resultado ejecutable: Qué ocurre cuando se desencadena (pago, liberación de capital, etc.)
En lugar de "Prometo pagarte 50.000 dólares cuando alcances los 100.000 dólares de MRR", una Tokenized Promise codifica:
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)
La lógica es explícita. La ejecución es automática. El registro de auditoría es permanente.
Arquitectura: Dos caminos, el mismo estándar
Estamos construyendo Tokenized Promise como un estándar abierto que cualquiera puede implementar. Además de eso, estamos construyendo una capa UX rica que lo hace accesible a los usuarios no técnicos.
Pero aquí está la clave: no todo el mundo quiere (o puede usar) la infraestructura de blockchain. Los requisitos regulatorios varían. Las capacidades técnicas difieren. Por lo tanto, admitimos dos modos de despliegue:
Modo Enterprise (Backend Gestionado)
Para las organizaciones que necesitan cumplimiento, auditabilidad y control, sin la complejidad de blockchain.
// Enterprise Tokenized Promise - Server-side
interface EnterprisePromise {
id: string;
parties: {
promisor: Party; // Who's making the promise
beneficiary: Party; // Who receives if fulfilled
arbitrator?: Party; // Optional dispute resolver
};
conditions: Condition[];
escrow: {
amount: number;
currency: string;
custodian: 'athanor' | 'bank' | 'custom';
};
verification: {
type: 'oracle' | 'attestation' | 'multi-sig';
sources: VerificationSource[];
threshold: number; // How many sources must agree
};
dispute: {
window: Duration; // Time to raise dispute after trigger
resolution: 'arbitration' | 'mediation' | 'court';
jurisdiction: string;
};
compliance: {
kyc: boolean;
aml: boolean;
jurisdiction: string[];
reportingRequirements: Report[];
};
}
Cómo funciona:
- Las partes firman el acuerdo (firmas digitales, legalmente vinculante)
- Los fondos se mantienen en depósito en garantía regulado (cuenta bancaria o custodio con licencia)
- Athanor monitorea las condiciones a través de fuentes de datos integradas
- Cuando se activa, los fondos se mueven automáticamente (dentro de los carriles regulatorios)
- Pista de auditoría completa para informes de cumplimiento
Ideal para:
- Entidades reguladas (fondos, family offices)
- Acuerdos transfronterizos que requieren jurisdicciones específicas
- Organizaciones con requisitos de cumplimiento
- Acuerdos en los que las contrapartes no tienen infraestructura criptográfica
Modo Self-Custody (Contratos Inteligentes)
Para aquellos que quieren una ejecución sin confianza: ningún intermediario puede bloquear o modificar la promesa una vez desplegada.
// 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.
}
Cómo funciona:
- Promesa creada en la cadena con las condiciones codificadas
- Fondos bloqueados en el contrato inteligente (ningún tercero puede acceder)
- Oráculos aprobados envían pruebas cuando se cumplen las condiciones
- El contrato libera automáticamente los fondos cuando se alcanza el umbral
- El mecanismo de controversia permite impugnar dentro de un plazo definido
Ideal para:
- Partes nativas de cripto
- Requisitos de ejecución sin confianza
- Acuerdos globales sin restricciones jurisdiccionales
- Máxima transparencia y auditabilidad
La capa de verificación
Ambos modos comparten la misma arquitectura de verificación. Aquí es donde Tokenized Promise se pone interesante.
Tipos de Oráculo
type OracleType =
| 'financial' // Revenue, MRR, burn rate (via accounting integrations)
| 'product' // DAU, retention, feature launches (via analytics)
| 'legal' // Incorporation, IP filing, compliance (via legal APIs)
| 'human' // Expert attestation, board approval
| 'composite'; // Combination of above
interface Oracle {
id: string;
type: OracleType;
trustScore: number; // Historical accuracy
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'
}
};
Verificación de múltiples fuentes
Para promesas de alto riesgo, la verificación de una sola fuente no es suficiente:
const milestoneVerification = {
condition: 'mrr_reaches_100k',
// Require 2 of 3 sources to agree
threshold: 2,
sources: [
{ oracle: 'stripe-mrr-oracle', weight: 1 },
{ oracle: 'quickbooks-revenue', weight: 1 },
{ oracle: 'cfo-attestation', weight: 1 }
],
// Tolerance for minor discrepancies
tolerance: {
type: 'percentage',
value: 0.05 // 5% variance allowed
},
// What happens on disagreement
disagreementResolution: 'arbitration'
};
Resolución de disputas: la red de seguridad
Incluso con la verificación automática, surgen disputas. Nuestro sistema de resolución multicapa se encarga de ellas:
Capa 1: Resolución automatizada
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'
}
];
}
Capa 2: Arbitraje humano
Cuando las reglas automatizadas no pueden resolver:
interface ArbitrationProcess {
arbitrators: {
pool: 'athanor_certified' | 'jams' | 'custom';
selection: 'random' | 'mutual_agreement' | 'rotating';
count: 1 | 3 | 5; // Odd number for majority
};
process: {
submissionWindow: '7d';
responseWindow: '7d';
deliberationWindow: '14d';
appealable: boolean;
};
costs: {
filing: number;
arbitratorFee: number;
allocation: 'loser_pays' | 'split' | 'proportional';
};
}
Capa 3: Escalamiento legal
Para los casos que requieren intervención judicial:
interface LegalEscalation {
jurisdiction: string;
governingLaw: string;
venue: string;
// Evidence package automatically generated
evidenceBundle: {
originalAgreement: Document;
transactionHistory: Transaction[];
oracleAttestations: Attestation[];
communicationLog: Message[];
disputeRecord: DisputeRecord;
};
}
Casos de uso del mundo real
1. Inversión basada en hitos
El problema: El inversionista quiere financiar en tramos vinculados a los hitos. Actualmente requiere seguimiento manual, llamadas trimestrales y la confianza de que el fundador informará honestamente.
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'
}
]
};
Resultado: El inversor confía en que los hitos se rastrean objetivamente. El fundador tiene objetivos claros con la liberación automática de fondos. No hay llamadas trimestrales de "¿ya llegamos?".
2. Acciones para asesores con "dientes"
El problema: Al asesor se le prometió un 0,5% por las presentaciones. La empresa crece, "olvida" el trato, el asesor no tiene influencia.
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'
}
};
Resultado: El asesor tiene una prueba criptográfica del acuerdo. Los hitos son verificados por varias partes. No hay "él dijo, ella dijo".
3. Acuerdos de reparto de ingresos
El problema: El creador de contenido tiene un acuerdo de reparto de ingresos con la plataforma. La plataforma informa lo que quiere. El creador no tiene derechos de auditoría.
const revenueShare = {
parties: {
creator: 'creator_wallet_or_account',
platform: 'platform_entity'
},
terms: {
percentage: 0.30, // 30% to creator
metric: 'net_revenue_from_content',
paymentFrequency: 'monthly'
},
verification: {
primary: 'platform_analytics_api',
secondary: 'third_party_audit_quarterly',
discrepancyThreshold: 0.10 // 10% triggers audit
},
payment: {
automatic: true,
currency: 'usd',
method: 'bank_transfer' // or 'crypto' in self-custody mode
}
};
Resultado: El creador recibe pagos automáticos vinculados a métricas verificadas. La plataforma no puede subestimar los informes. Las disputas desencadenan una auditoría automática.
4. Adquisición de derechos de los empleados con desencadenantes objetivos
El problema: El empleado tiene una adquisición de derechos de 4 años con disposiciones de "buen saliente". La empresa decide lo que significa "bueno" cuando le conviene.
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' // Requires termination too
},
{
trigger: 'termination_without_cause',
verification: ['hr_system', 'legal_review'],
acceleration: '6_months'
}
],
goodLeaver: {
definition: 'explicit', // Not "at board discretion"
conditions: [
'resignation_with_notice',
'termination_without_cause',
'disability',
'death'
],
verification: 'hr_oracle_plus_attestation'
}
};
Resultado: El empleado sabe exactamente qué desencadena qué. No hay sorpresas de "discreción de la junta directiva". La aceleración es automática cuando se verifican las condiciones.
Cumplimiento incorporado
Tokenized Promise está diseñado para el mundo regulado:
Integración 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, // For securities-related promises
verification: 'verify_investor' | 'manual',
reVerification: '90_days'
}
};
Ejecución consciente de la jurisdicción
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 Hoja de Ruta
2026: Dar forma y validar
Este año se trata de hacer bien la base:
- Q1-Q2: Lanzamiento con 2 Tokenized Promises en vivo (contrapartes reales, apuestas reales)
- Q2-Q3: Código abierto de la especificación estándar
- Q3-Q4: Implementar modos enterprise y self-custody basados en los comentarios de los primeros usuarios
- En curso: Iteración en oráculos de verificación, resolución de disputas, UX
No estamos construyendo en el vacío. Cada función se envía porque un usuario real la necesitaba.
2027: Maduro y Escala
El año que viene se trata del alcance:
- Madurar la red de oráculos (más fuentes de datos, mayores puntuaciones de confianza)
- Escalar la resolución de disputas (red de árbitros certificados)
- Ampliar la cobertura de la jurisdicción
- Lanzar un mercado para plantillas de Tokenized Promise
- Habilitar la composabilidad (promesas que desencadenan otras promesas)
El circuito cerrado
Esta es la visión: cada compromiso en Athanor se convierte en una Tokenized Promise.
- El fundador presenta la idea -> se compromete con los hitos a través de TP
- Financiación del inversor -> tramos liberados a través de TP
- El asesor se une -> el capital se adquiere a través de TP
- Empleado contratado -> adquisición de derechos rastreada a través de TP
Cada promesa verificada. Cada resultado rastreado. Cada disputa resoluble.
No porque no confiemos en la gente, sino porque los compromisos claros facilitan la confianza.
Involúcrate
Estamos buscando activamente:
Primeros usuarios: Inversores y fundadores dispuestos a estructurar acuerdos reales como Tokenized Promises. Trabajaremos en estrecha colaboración con usted en la implementación.
Socios legales: Firmas interesadas en desarrollar plantillas y opiniones específicas de la jurisdicción.
Colaboradores técnicos: El estándar será de código abierto. Ayúdanos a construirlo bien.
Comentarios: Incluso si no está listo para usarlo, díganos qué haría que esto sea valioso para su flujo de trabajo.
¿Listo para explorar Tokenized Promise para su próximo acuerdo? Hablemos.
