INTEGYRS separates the ownership record, encrypted content, authorization mechanism and endpoint. Each layer has a specific job and an explicit trust boundary.
This conceptual map shows the components under development. Current access nodes and endpoints run as software scaffolding. The protected-device path is a separate engineering milestone.
Authorises a change of recognised possession.
Records candidate ownership transactions.
Supplies evidence used by the access policy.
Stores sections separately from possession state.
Provides recipient-bound contributions when eligible.
Software today. Protected processing and rendering to be validated.
The application recognises a current possession state and a valid successor. A ledger can contribute transaction and inclusion evidence; the application still needs explicit rules for which transitions it accepts.
A signature, a matching inclusion path, an authenticated chain and a fresh current-state observation are different pieces of evidence. None, on its own, proves protected rendering.
The experimental mechanism requires sufficient valid contributions for section-level access, bound to an intended recipient. Eligibility must reflect the relevant ownership and freshness policy.
When evidence is missing, stale or contradictory, the target behavior is to refuse fresh access until state is reconciled. Independent deployment, custody and production hardening remain open.
The protected-path goal is to verify contributions, derive access, decrypt and render inside a boundary that does not export sensitive material to the ordinary application or host.
Hardware-backed key storage alone does not establish that path. Attestation, trusted freshness, rollback resistance and active-display clearing must be measured together.
The design direction combines competing eligible remote providers with a compulsory protected-device factor. No single provider should unlock the work; the precise construction must also define what happens when providers collude. Remote responses addressed to a device are not, by themselves, proof that a malicious quorum cannot bypass it.
The intended endpoint processes only the authorised page, information unit, frame or bounded computation. No whole-work plaintext object is assembled anywhere in the reader, and the ordinary host receives neither protected content keys nor content plaintext. This is a future architecture target, not a result established by the current alpha.
Protected memory, trusted input/output, authenticated firmware, anti-rollback state and a safe update/recovery path must make that rule survive a malicious host. Smaller units and stronger hardware add real processing and operating costs; price and performance must be measured.
Explore the threshold-and-device construction →Later development is planned to investigate off-chain proofs and verification mechanisms, with their exact trust, freshness and settlement requirements made explicit.
That work is separate from copyright management and from offline access. Neither capability is supplied by the current alpha. A future proof mechanism must be evaluated on what it actually verifies, rather than treated as a general guarantee of ownership or device security.
Transfers, restarts and changing chain observations can leave access uncertain. The next step must be determined by evidence, rather than by whichever component answered last.
Treat pending transfer, conflicting state and reorganisation as explicit conditions. Keep chain and mempool observations distinct.
Recover the canonical view and establish which operations were durably authorised before resuming eligible access.
Exercise old capabilities, retained ciphertext, replay and rollback together. A successful happy path cannot establish the failure boundary.
Hardware designs are in development. The present software experiments do not yet verify that architecture. A device evaluation must identify the exact platform, build, secure execution facilities and unsupported operations.
The acceptance gate covers the complete path from a fresh authorization to a controlled display, including reboot, rollback, interruption, expiry and key exposure. If a platform cannot meet the stated boundary, the supported claim must change.
Read the device acceptance gateExplore what digital scarcity changes, how the current protocol works, and the infrastructure, hardware and published inventions behind the longer-term direction.
Copyable files, transferable authority, least-privilege use and the potential to reduce host-visible information exposure.
Read the foundations → CHAPTER 01 / SOFTWARE MODELMinting, independently encrypted sections, threshold contributions, two fresh observations and the exact receipt/freeze boundary.
Read the protocol → CHAPTER 02 / DEVICE DESIGNCompeting threshold providers and compulsory hardware, fixed trust anchors, protected unit processing and the hostile-host test plan.
Read the hardware architecture → CHAPTER 03 / INFRASTRUCTUREDistributed transaction-processing services, state and storage, throughput context and the separate rates of settlement and device use.
Read the scalability analysis → CHAPTER 04 / PUBLISHED RECORDSEight linked US patent grant publications covering related key, recovery, credential, content and exchange mechanisms.
Read the patent register → ASSURANCE / ADVERSARIAL MODELCurrent software limits, future device guarantees, collusion, output leakage, privacy and the obligations created by recovery.
Read the security model →