UTXOSUITE — home
LABS / ORGANIZACIÓN DE CONSTRUCCIÓN

Disciplinas separadas. Reglas de entrega compartidas.

Labs explica la organización de trabajo alrededor de UTXO Suite y sistemas hermanos. No certifica tamaño de equipo, revisión externa ni preparación para producción; esos estados pertenecen a cada proyecto y su evidencia.

UNIDADES DE CONSTRUCCIÓN

Infraestructura y software aplicado siguen siendo distinguibles.

UTXO Labs Team e Idovio Team pueden colaborar conservando alcances diferentes. La frontera es descriptiva y no significa que toda capacidad nombrada esté ya publicada.

UNIT 01

UTXO Labs Team

UTXO Labs Team se concentra en protocolos, seguridad, análisis transaccional, routing e investigación de sistemas. En UTXO Suite se refleja en SafeSign, Security Core y el modelo de integración de seguridad.

TRANSACTION SECURITY
SYSTEMS / PROTOCOL RESEARCH
ROUTING / ANALYSIS
UNIT 02

Idovio Team

Idovio Team se concentra en software de aplicación y producto. Las aplicaciones hermanas y sistemas experimentales de productividad permanecen separados de la promesa central de seguridad transaccional.

APPLICATION SOFTWARE
PRODUCT ENGINEERING
SIBLING SYSTEMS
DISCIPLINA DE ENTREGA

El estado forma parte de la arquitectura.

Un proyecto puede pasar por research, scaffold, prototipo, superficie integrada y release de producción. El sitio debe conservar esas diferencias.

RULE 01

LOCAL-FIRST

LOCAL-FIRST CUANDO ES PRÁCTICO — análisis y preferencias sensibles permanecen en dispositivo cuando la integración lo permite.

RULE 02

NON-CUSTODIAL

NO CUSTODIAL — las superficies de seguridad no necesitan custodiar claves privadas para explicar una solicitud.

RULE 03

EXPLICIT AUTHORIZATION

AUTORIZACIÓN EXPLÍCITA — el análisis informa; usuario o wallet conserva el límite de firma.

RULE 04

EVIDENCE-LED STATUS

ESTADO BASADO EN EVIDENCIA — shipped, audited, peer-reviewed y production-ready solo se usan con soporte real.

MODELO OPERATIVO

Mueve el trabajo mediante gates de ingeniería explícitos.

Haz explícito el camino de research a producción: artefactos, límites de seguridad y estados deben avanzar juntos.

01 / DISCOVERY

DISCOVERY

Define problema, threat model y qué permanece fuera del trust boundary.

02 / SPECIFICATION

SPECIFICATION

Escribe invariantes, inputs soportados, comportamiento de fallo y tests negativos antes de implementar.

03 / VALIDATION

VALIDATION

Ejecuta fixtures positivos, negativos, adversariales y de regresión antes de elevar el estado.

GATES DE MADUREZ

El estado se convierte en control de release, no en adjetivo de marketing.

Haz explícito el camino de research a producción: artefactos, límites de seguridad y estados deben avanzar juntos.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
RESEARCH
problem + hypothesis
Existe una dirección; no implica implementación.
RESEARCH
SCAFFOLD
source + checks
Existe código pero la integración real puede seguir incompleta.
SCAFFOLD
RELEASE
validation + ops
Existen release artifact, rollback path y evidencia operativa.
RELEASE
RELEASE RECORD
{
  "surface":"guard",
  "stage":"integrated",
  "required":["real provider flow","negative fixtures","payload-integrity test"],
  "publicLabel":"BETA"
}
SECURITY GATE
{
  "privateKeyCustody":false,
  "autoSign":false,
  "payloadMutation":"forbidden",
  "unsupportedInput":"visible failure"
}
LABS RULE

Una interfaz pulida puede existir antes de que el backend esté completo, pero el estado público debe describir esa diferencia exactamente.