UTXOSUITE — home
LABS / ORGANIZZAZIONE

Discipline separate. Regole di delivery condivise.

Labs spiega l'organizzazione attorno a UTXO Suite e sistemi fratelli senza certificare dimensione team, external review o production readiness.

UNITÀ

Infrastruttura e software applicato restano distinguibili.

UTXO Labs Team e Idovio Team possono collaborare mantenendo scope diversi; non significa che ogni capability sia shipped.

UNIT 01

UTXO Labs Team

UTXO Labs Team si concentra su protocollo, sicurezza, transaction analysis, routing e systems research; in UTXO Suite emerge tramite SafeSign e Security Core.

TRANSACTION SECURITY
SYSTEMS / PROTOCOL RESEARCH
ROUTING / ANALYSIS
UNIT 02

Idovio Team

Idovio Team si concentra su application/product software. App sorelle ed esperimenti restano separati dalla promessa centrale.

APPLICATION SOFTWARE
PRODUCT ENGINEERING
SIBLING SYSTEMS
DISCIPLINA DI DELIVERY

Lo status è parte dell'architettura.

Research, scaffold, prototype, integrated surface e production release sono fasi distinte.

RULE 01

LOCAL-FIRST

LOCAL-FIRST QUANDO PRATICO — analisi sensibile e preferenze sul device.

RULE 02

NON-CUSTODIAL

NON-CUSTODIAL — spiegare request non richiede private-key custody.

RULE 03

EXPLICIT AUTHORIZATION

AUTORIZZAZIONE ESPLICITA — user/wallet resta signing boundary.

RULE 04

EVIDENCE-LED STATUS

STATUS BASATO SU EVIDENCE — label forti solo con supporto reale.

MODELLO OPERATIVO

Fai avanzare il lavoro attraverso gate ingegneristici espliciti.

Rendi esplicito il percorso research→production: artefatti, security boundaries e status avanzano insieme.

01 / DISCOVERY

DISCOVERY

Definisci problema, threat model e ciò che resta fuori dal trust boundary.

02 / SPECIFICATION

SPECIFICATION

Scrivi invarianti, input supportati, failure behavior e negative tests prima di implementare.

03 / VALIDATION

VALIDATION

Esegui fixture positivi, negativi, adversarial e regression prima di alzare lo status.

GATE DI MATURITÀ

Lo status diventa controllo di release, non aggettivo marketing.

Rendi esplicito il percorso research→production: artefatti, security boundaries e status avanzano insieme.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
RESEARCH
problem + hypothesis
La direzione esiste; implementation non è implicita.
RESEARCH
SCAFFOLD
source + checks
Il codice esiste ma l'integrazione reale può restare incompleta.
SCAFFOLD
RELEASE
validation + ops
Esistono release artifact, rollback path ed evidence 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 UI curata può esistere prima del backend completo, ma lo status pubblico deve descrivere esattamente la differenza.