INTEGYRS
05 / Roadmap

From working software
to protected devices.

The ambition is device-level digital scarcity. Progress is measured through acceptance gates, so each stronger claim arrives with the evidence it needs.

SOFTWARE ALPHA: WORKINGHARDWARE DESIGN: UNDERWAYDEVICE ARCHITECTURE: NOT YET VALIDATED
Development sequence

Six gates.
A planned path to launch.

The current plan targets a beta in early 2027 and a live rollout within 18 months of October 2026, by April 2028. These are development targets, subject to the acceptance gates below. Work can run in parallel; a later stage does not waive an earlier security gate.

00
Public website / technical expansion

Identity and evidence baseline.

Maintain the public INTEGYRS brand, detailed technical explanation and dated evidence register. Add verified contact and operational details as they become available. The public website is a documentation baseline, not the launch of the protected-device product.

Acceptance evidence

  • Confirm domain, identity assets and monitored contact
  • Approve exact public files and disclosures
  • Trace every factual claim to a stable, reviewed source
  • Verify final hosted privacy settings, headers and access
01
Bounded experiments recorded

Connect chain state to access.

Develop reproducible end-to-end behavior across mint, transfer, prior-holder refusal, successor access, conflict, reorganisation and interruption. Private-node work provides a starting point.

Current bounded evidence

Acceptance evidence

  • Authenticated, fresh state consumed by the access path
  • Exact-version capability and decryption outcomes
  • Both freeze race orders and failure boundaries documented
  • Reproducible recovery with explicit stale-state and mempool limits
02
Design work underway / unvalidated

Prove the protected device path.

Develop and evaluate hardware versions with a measured capability matrix for each device. Build a protected path where platform facilities permit it. Hardware designs are underway; no proposed hardware version has yet passed the device gate.

Acceptance evidence

  • Exact device, OS build, patch state and genuine attestation
  • No host-OS access to protected keys or content plaintext
  • No whole-work plaintext object; bounded protected page/unit/frame processing
  • Vendor-supported protected parsing, computation, input/output and display
  • Trusted freshness and rollback-resistant records
  • Display expiry, clearing, interruption and capture tests
  • Unsupported operations fail closed; narrow the claim if needed
03
Planned

Review cryptography and custody.

Move from a research composition toward reviewed production components, independently operated access nodes and a complete key lifecycle.

Acceptance evidence

  • Independent composition and implementation review
  • Production hardening with no unresolved critical issues
  • Tested generation, distribution, refresh, backup and recovery
  • Explicit quorum-compromise and custody assumptions
  • Separately reviewed compulsory-device factor, tested against malicious remote coalitions
  • Eligible provider competition, independence and authenticated membership transitions
  • A versioned protocol profile and conformance decision
  • Explicit maps for key recovery, authority, proof and rotation
04
Planned

Run a controlled pilot.

Start with an approved public-network experiment using disposable test material, then a narrow consenting pilot with rights-cleared content and defined endpoints.

Acceptance evidence

  • Propagation, fees, policy and settlement monitoring
  • Reorganisation response, privacy and abuse controls
  • Successful access and false refusals reported separately
  • Recovery, latency and usability measured with sample sizes
  • Content rights, participant consent and support scope agreed
05
Planned

Support a product. Expand carefully.

Target a staged live rollout by April 2028, with stable integration for a specific supported platform and threat model. Later hardware versions and extended capabilities must each earn their own evidence before support is claimed.

Acceptance evidence

  • Stable APIs or SDK with documented compatibility
  • Signed releases and update/revocation policies
  • Operator runbooks, incident response and support
  • Measured reliability and validated commercial terms
  • Independent review and pilot findings justify the supported claim
Parallel engineering tracks

Validate the device.
Scale the system.

Hardware and infrastructure work can progress together, but neither waives the other’s evidence requirements. The current private-node alpha has not demonstrated Teranode or a hardware-protected reader.

A / PROTECTED COMPUTATION

Per-unit enforcement.

Implement the minimum protected working set; test hostile-host extraction, secure I/O, debug/DMA/fault conditions, buffer retirement and firmware/possession rollback.

Hardware architecture →
B / THRESHOLD SERVICES

Compete without weakening trust.

Specify independent providers, compulsory device participation, malicious-quorum assumptions, key/share changes, output privacy and selection economics. No production parameters or pricing are yet fixed.

Threshold design →
C / TRANSACTION INFRASTRUCTURE

Measure a Teranode integration.

Pin versions and representative workloads. Measure settlement, fresh observations, access latency, failures, storage and operating costs separately; do not inherit a headline TPS claim.

Scalability evaluation →
Planned recovery design

Map the authority.
Prove the recovery.

These are proposed pathways for later versions, not implemented alpha features. Each must specify who may act, what proof is required, which keys rotate and how duplicate possession is prevented.

Future pathway / lost device

Owner authority survives.

Prove control of the surviving owner authority, validate the replacement endpoint, retire the old device identity and issue fresh access material.

Map: owner proof → replacement attestation → old-device retirement → key rotation → one recognised successor.

Future pathway / compromised key

Quarantine before replacement.

A potentially compromised owner key cannot be the sole authority for a safe recovery. Define an independently authorised recovery route in advance, with explicit proof and dispute handling.

Map: compromise evidence → access hold → recovery-authority decision → key replacement → verified resumption.

Future pathway / sole key lost

Recovery must be arranged.

The alpha cannot recover a lost sole owner signing key. A later design would need a previously established recovery authority and policy; a new device alone does not recreate that authority.

Map: prior recovery policy → admissible proof → bounded authorisation → new key binding → auditable transition.

Future pathway / access-key rotation

Version the change.

Plan recipient and committee-key rotation, retention rules and fresh-state checks across hardware versions. Rotation cannot recall plaintext or secrets already disclosed to a compromised party.

Map: affected-key inventory → approved rotation authority → fresh epoch → old-material refusal → recovery tests.

The principle

Keep the ambition.
Earn the assurance.

Complete device-level digital scarcity is the research ambition. A successful software test or a single supported platform cannot establish a universal result.

Our roadmap keeps that ambition intact while making the next engineering question concrete: what must this particular device, protocol and operating model demonstrate?

Revisit the security boundaries

Know what works today.
See what comes next.

Review current evidence