CM-08 · Tokenización de instrumentos#

En una frase, para cualquiera: convertir un activo en fichas digitales permite venderlo en trozos pequeños. El problema es asegurarse de que la suma de las fichas no supere nunca lo que hay detrás.

Estado real: 🟠 prototype — hay código y escenarios que se ejecutan, sin verificación en un entorno real · Módulo: crates/sandbox-markets/src/cases/tokenization.rs

Por qué se realiza este caso#

La tokenización promete fraccionar, transferir rápido y registrar de forma inalterable. Cada una de esas promesas tiene una forma de romperse:

La desincronización es la más peligrosa porque el token no es el activo: es una anotación. Si el registro legal dice que el dueño es otro, el token no gana la discusión.

La idea que enseña, y que ningún otro caso enseña#

El respaldo es un invariante, no una promesa. unidades emitidas ≤ respaldo registrado, comprobado en cada emisión, transferencia y rescate. Es hermano del invariante de CM-03, y por la misma razón: cuando se rompe, alguien tiene un papel que no vale lo que dice.

Casos de uso reales#

• Fraccionar un inmueble o un fondo entre muchos inversionistas.
• Representar digitalmente instrumentos de deuda.
• Un registro de propiedad con transferencias sujetas a restricciones.
• Formación: por qué un token no es el activo.

Cómo funcionará#

flowchart LR
  A["🏢 Activo respaldo"] --> E["🪙 Emisión"]
  E --> R["📒 Registro de propiedad"]
  R --> T{"↔️ Transferencia"}
  T -->|"permitida"| R
  T -->|"restringida"| X["🚫 Rechazada con motivo"]
  R --> D["💰 Distribuciones"]
  R --> RD["♻️ Rescate y vencimiento"]
  R --> F["❄️ Congelamiento"]
  E & T & RD --> I["🔍 Invariante:<br/>emitido ≤ respaldo"]

flowchart TB
  A["Transferencia solicitada"] --> B{"¿El destinatario cumple<br/>las restricciones?"}
  B -- no --> B1["🚫 Rechazada: restricción de tenencia"]
  B -- sí --> C{"¿Las unidades están<br/>congeladas?"}
  C -- sí --> C1["🚫 Rechazada: congelamiento"]
  C -- no --> D{"¿El registro legal<br/>coincide con el digital?"}
  D -- no --> D1["🚨 Desincronización"]
  D -- sí --> E["✅ Transferida y anotada"]

Esquemas#

{
  "issuance": {
    "instrument": "INMUEBLE-SIM-1",
    "backing": { "appraised": { "minorUnits": 500000000, "currency": "CLP" }, "registryRef": "sim-legal-001" },
    "unitsIssued": 5000,
    "unitValue": { "minorUnits": 100000, "currency": "CLP" },
    "restrictions": ["qualified-investors-only"]
  }
}

{
  "findings": [
    { "kind": "OverIssuance", "instrument": "INMUEBLE-SIM-1", "issued": 5200, "maxByBacking": 5000 },
    { "kind": "LegalDesync", "instrument": "INMUEBLE-SIM-1", "digitalOwner": "cli-3", "legalOwner": "cli-7" }
  ]
}

Software necesario#

No usa cadena de bloques real ni conectividad externa: el registro es un libro append-only local. Sin jaula ni Linux.

Instalación#

cargo build --release

Procesos que se crearán#

sandboxctl markets tokenize --scenario sobreemision
  │
  └─ un proceso determinista, sin red
      ├─ registro append-only
      └─ invariante comprobado tras cada operación

Tiempo de carga estimado#

Qué hace falta para construirlo#

1. Registro de propiedad append-only, con reconstrucción completa.
2. Invariante emitido ≤ respaldo, comprobado tras cada operación.
3. Restricciones de tenencia y transferencia, declarativas.
4. Congelamiento, rescate y vencimiento.
5. Conciliación entre registro digital y registro legal simulado.
6. Integración con CM-17 para distribuciones.

Si algo falla#

El caso ya tiene código y escenarios que se ejecutan. Lo que sigue son sus fallos con la causa y la salida:

Los fallos que afectan a cualquier caso —la compilación, el catálogo, la evidencia— están resueltos uno a uno en Cuando algo falla.

Esta familia no necesita aislamiento del sistema: no ejecuta código ajeno, sino reglas de negocio deterministas. Por eso casi ningún fallo suyo viene del entorno, y casi todos vienen de los datos.

Cómo se comprueba#

cargo run -p sandboxctl -- markets check --case CM-08

Ejecuta los escenarios de este caso y compara cada uno con lo que declara de antemano que debe salir. Corre en cada commit: si el caso deja de detectar lo que dice detectar, la integración continua se pone roja.

cargo test -p sandbox-markets tokenization

Los invariantes del módulo, incluidos los que ningún escenario de arriba cubre.

Sigue en prototype, no en functional. Los escenarios se ejecutan y pasan, pero el caso no emite evidencia firmada por ejecución ni se ha usado contra datos que no sean los suyos. La regla completa está en el ROADMAP.

Ver también: Catálogo completo · CM-03 · custodia · CM-17 · eventos corporativos