UTXOSUITE — home
RESEARCH / WORKING INDEX

Evidence before publication labels.

This index tracks research directions that are visible in the repository or directly connected to active product work. A design note is a design note; a source scaffold is a scaffold. Nothing here is called peer-reviewed, audited or published unless there is evidence for that status.

CURRENT DIRECTIONS

Research connected to implementation.

The useful boundary is between an idea, a specification, a prototype and a production capability. These areas are kept visible without collapsing those stages.

TRACK 01ACTIVE DIRECTION

Transaction interpretation

Transaction-request decoding, authority scope, destination context and uncertainty presentation around SafeSign and Security Core.

TRACK 02ACTIVE DIRECTION

Browser request boundaries

Browser interception boundaries for wallet-provider requests, including page-context wrapping and local-only preference storage in the Guard scaffold.

TRACK 03ACTIVE DIRECTION

Bitcoin / PSBT review

Bitcoin PSBT preview and route-intelligence concepts, with signing and route execution kept separate from current analysis surfaces.

TRACK 04ACTIVE DIRECTION

Security education

Security education through transaction labs: approvals, typed data, Permit2, phishing, proxies, simulation divergence and incident-response scenarios.

STATUS DISCIPLINE

A research page should not manufacture authority.

Public labels are treated as claims. The site therefore uses conservative status language and points readers toward code, documentation and project pages rather than invented paper identifiers.

STATUS 01

IDEA

IDEA — direction under consideration; not an implemented capability.

STATUS 02

SPEC / NOTE

SPEC / NOTE — documented behavior or design constraint; not automatically peer-reviewed.

STATUS 03

SCAFFOLD / PROTOTYPE

SCAFFOLD / PROTOTYPE — code exists, but build, integration or production validation may remain.

STATUS 04

PRODUCT SURFACE

PRODUCT SURFACE — visible capability with its trust boundary stated separately from future work.

Read developer documentationExplore project index
RESEARCH PROGRAM

Turn security questions into falsifiable engineering work.

Every direction should define a threat, hypothesis, test artifact and evidence gate before a stronger public claim is allowed.

01 / INTENT ↔ PAYLOAD

INTENT ↔ PAYLOAD

Test whether decoded authority materially exceeds the user's stated action.

02 / SIMULATION DIVERGENCE

SIMULATION DIVERGENCE

Model mutable state and conditional paths that can separate benign simulation from real execution.

03 / AUTHORITY SCOPE

AUTHORITY SCOPE

Quantify lifetime and blast radius of approvals, Permit and Permit2.

CLAIM GATES

A stronger label requires a stronger artifact.

Every direction should define a threat, hypothesis, test artifact and evidence gate before a stronger public claim is allowed.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
IDEA
threat + hypothesis
Question is explicit and falsifiable.
IDEA
PROTOTYPE
code + fixtures
Artifact can be reproduced in the repository.
PROTOTYPE
VALIDATED
tests + independent evidence
Claim is bounded by what validation proves.
EVIDENCE
RESEARCH RECORD
{
  "threat":"simulation divergence",
  "hypothesis":"mutable execution context can invalidate benign previews",
  "artifact":"fixture-suite/simulation-divergence",
  "status":"prototype"
}
PUBLIC CLAIM GATE
{
  "allowed":"prototype demonstrates selected divergence cases",
  "notAllowed":["audited","peer-reviewed","complete protection"],
  "evidenceRequired":["reproducible tests","independent review"]
}
RESEARCH RULE

No paper title, audit label or validation claim without an inspectable artifact or independent evidence.