UTXOSUITE — home
LABS / BUILD ORGANIZATION

Separate disciplines. Shared delivery rules.

Labs explains the build organization around UTXO Suite and sibling systems. It does not certify team size, external review or production readiness. Those statuses belong to the specific project and its evidence.

BUILD UNITS

Infrastructure and applied software stay distinguishable.

UTXO Labs Team and Idovio Team can collaborate across the ecosystem while retaining different scopes. The boundary is descriptive, not a claim that every named capability is already shipped.

UNIT 01

UTXO Labs Team

UTXO Labs Team focuses on protocol, security, transaction analysis, routing and systems research. In UTXO Suite, that work is represented by SafeSign, Security Core and the security-oriented integration model.

TRANSACTION SECURITY
SYSTEMS / PROTOCOL RESEARCH
ROUTING / ANALYSIS
UNIT 02

Idovio Team

Idovio Team focuses on application and product-layer software. Sibling applications and experimental productivity systems remain separate from the core UTXO Suite transaction-security promise.

APPLICATION SOFTWARE
PRODUCT ENGINEERING
SIBLING SYSTEMS
DELIVERY DISCIPLINE

Status is part of the architecture.

A project can move through research, source scaffold, prototype, integrated surface and production release. The site should preserve those distinctions instead of marketing them away.

RULE 01

LOCAL-FIRST

LOCAL-FIRST WHERE PRACTICAL — sensitive analysis and preferences stay on-device when the integration permits it.

RULE 02

NON-CUSTODIAL

NON-CUSTODIAL — transaction-security surfaces do not need private-key custody to explain a request.

RULE 03

EXPLICIT AUTHORIZATION

EXPLICIT AUTHORIZATION — analysis may inform; the user or calling wallet remains the signing boundary.

RULE 04

EVIDENCE-LED STATUS

EVIDENCE-LED STATUS — shipped, audited, peer-reviewed and production-ready are used only when support exists.

OPERATING MODEL

Move work through explicit engineering gates.

Make the path from research to production explicit: required artifacts, security boundaries and status labels must advance together.

01 / DISCOVERY

DISCOVERY

Define user problem, threat model and what remains outside the trust boundary.

02 / SPECIFICATION

SPECIFICATION

Write invariants, supported inputs, failure behavior and negative tests before implementation.

03 / VALIDATION

VALIDATION

Run positive, negative, adversarial and regression fixtures before status is upgraded.

MATURITY GATES

Status becomes a release control, not a marketing adjective.

Make the path from research to production explicit: required artifacts, security boundaries and status labels must advance together.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
RESEARCH
problem + hypothesis
Direction exists; implementation is not implied.
RESEARCH
SCAFFOLD
source + checks
Code exists but real integration may remain incomplete.
SCAFFOLD
RELEASE
validation + ops
Release artifact, rollback path and operating evidence exist.
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

A polished interface may exist before a backend is complete, but public status must describe that difference exactly.