A possession is state, authority and a permitted use.
INTEGYRS explores a specific kind of digital scarcity: one system-recognised possession at a time, with fresh access governed by its current authority. The encrypted file can be copied and cached. What should not be freely duplicated is the system’s recognition that an arbitrary endpoint may turn that ciphertext into an authorised use.
The alpha separates an owner’s signing authority from the recipient endpoint’s decryption identity. An owner signature authorises a possession transition or request. A device key identifies the endpoint to which a usable access contribution is addressed. These are cryptographic identities inside the experiment, not verified legal identity or a statement about copyright.
A possession record combines an asset identifier, a recognised transaction output, owner and device identities, an epoch, and a commitment to the encrypted bundle and relevant context. The application must decide which predecessor and successor are valid; an ordinary transaction signature alone does not establish the complete application policy.
Current scope: the executable alpha models minting, section access, transfer, refusal and selected replacement/recovery behavior. It does not implement copyright management or copyright transfer. Its access path is online. Neither limitation is implied by the other.
The commercial opportunity is to make a recognised digital possession useful across an entire lifecycle rather than merely record a token. Candidate uses include a rights-cleared publication, controlled professional material, a licensed data operation or a device-bound entitlement. Each needs a separate rights agreement, product policy and validated endpoint.
Separate jobs. Explicit trust relationships.
| Component | Role in the alpha | Boundary |
|---|---|---|
| Owner authority | Signs requests and authorised possession transitions. | An ordinary software-held signing key; losing the sole owner key is unrecoverable in this profile. |
| Recipient endpoint | Proves key control, opens addressed contributions, verifies them and processes a section. | A software reader model with mock attestation, not a secure reader or protected physical display. |
| Possession state | Recognises one current state, confirmation depth and eligible successors. | A simulator plus a separate opt-in private-node bridge. Application uniqueness rules are not generic P2PKH consensus rules. |
| State observer | Responds to endpoint-generated challenges with signed state observations. | A pinned oracle authenticates its answer; the model still trusts its state source and wiring. |
| Access committee | Checks the request and produces recipient-bound contributions. | Five software nodes and a trusted dealer in one process; no independently operated custody network is demonstrated. |
| Durable coordinator | Stores intents, authorization fences, nonce/receipt state and local ordering. | SQLite transactions and a local audit chain; not tamper-proof hardware or a distributed consensus service. |
This separation makes assumptions visible. A threshold construction does not prove independent custody if all share holders are in the same process. A signed observer message does not make a dishonest observation true. A durable local transaction does not lock the external blockchain. The next engineering phases must turn these explicit interfaces into independently evaluated boundaries.
Create encrypted units before activating possession.
- Identify the asset and receiving endpoint.The software validates a canonical asset identifier and its mock owner/device binding. A permanent identifier registry prevents a duplicate logical mint through the same recognised route.
- Encrypt sections independently.Each section receives an independent random content key and authenticated ciphertext. A commitment binds the encrypted bundle and relevant ownership/device/policy context.
- Persist the pending creation.The coordinator records the mint intent before registration, allowing a retry to recover the same operation rather than accidentally create a second possession.
- Wait for the configured activation condition.Access is enabled only after the recognised genesis has the required confirmation depth. The experimental default is two confirmations; this is a test-profile choice, not a universally safe settlement rule.
The alpha explicitly refuses a request that asks it to satisfy a real secure-reader requirement. It does not silently substitute an ordinary application for hardware protection. That distinction is essential: a functioning software workflow is useful engineering evidence, but cannot establish a boundary that the operating system can inspect.
The present section model is the starting point for a future page, record or media-unit manifest. An actual content pipeline would have to define independent unit identifiers, dependencies, authenticated metadata, content versions and permitted operations. A full book should not become a single plaintext object merely because its encrypted sections share a common asset identity.
Threshold issuance with recipient binding.
The experimental construction uses AES-GCM for independently encrypted sections. A section’s random 256-bit content key is wrapped using a threshold Diffie–Hellman shared value and HKDF-SHA256. The default committee is three of five Shamir shares over secp256k1; each node’s contribution is encrypted to a separate P-256 endpoint key.
An honest share node validates the exact requested asset, section, possession state and recipient before producing its contribution. The contribution carries an equality-of-discrete-log proof, bound to the request and the relevant committee/section context. Conceptually, this allows the recipient to check that a contribution is consistent with the node’s committed key relationship without learning the node’s secret scalar.
Each contribution is encrypted to the intended endpoint. The coordinator can relay opaque envelopes rather than assemble a usable section key on behalf of the reader. The endpoint checks the context, verifies the proof and combines enough valid contributions before opening the section. The endpoint can discard invalid contributions and proceed if the required number of valid contributions remains. Invalid participant metadata, mismatched capability context or insufficient valid contributions cause refusal; the threshold is never lowered to make an outage look successful.
Research construction. This is a trusted-dealer experimental composition, not a claim of distributed key generation, independently reviewed production cryptography or non-exportable keys. The dealer knows sensitive setup material. A malicious threshold quorum can decrypt retained old ciphertext; the test suite deliberately demonstrates this limitation.
Transfer changes recognised possession and authorization eligibility. It does not re-encrypt every retained copy of the encrypted bundle or destroy ciphertext someone already holds. This is why custody assumptions, future key rotation and device isolation matter as much as the successful threshold calculation.
A capability is specific, short-lived and checked again.
The alpha binds an access capability to an asset and section, current owner and endpoint, content/state commitment, canonical epoch, recognised possession output, authorization fence, random single-use nonce, expiry and committee context. A valid capability for the wrong section, endpoint or state is not a general key to the work.
The default experimental lease is 15 seconds, with a configured upper bound of 60 seconds. These values are profile parameters, not a product latency promise. Exact issuance retries can return the cached capability, while a different request reusing the same challenge is refused.
- Challenge the state source.The endpoint generates an unpredictable challenge and verifies a fresh signed observation against the pinned oracle key.
- Check current eligibility.The observation must agree with the expected possession, authorization fence, recipient and time/expiry policy.
- Verify the contributions.The endpoint opens its addressed envelopes, checks the proofs and binding, combines the required threshold and decrypts the selected section inside the software model.
- Observe again.A second fresh signed observation checks for relevant state change across the processing window.
- Commit a durable receipt.The coordinator orders the render-receipt commitment against transfer freeze before returning the software operation result.
The two observations narrow a race window; they do not make a malicious oracle trustworthy. The durable receipt orders the final local authorization boundary; it does not turn the software process into a protected display. In this alpha, decryption already occurs in ordinary process memory and the “render” harness returns a receipt/byte-count result rather than operating secure physical output.
A previously issued, unconsumed capability may remain usable during a custody-node outage within its validity period, but the endpoint still needs the live oracle/chain observation path. That is not offline operation. “195 offline tests” describes where the tests execute, not an offline reader capability.
Freeze before releasing a signed transition.
Current holder
Eligible owner and endpoint can request fresh section access.
Unique intent
A successor is proposed and accepts. The current holder remains active.
Sign and fence
Durable freeze and spend signing occur together before signed intent release.
Submit & observe
Idempotent submission and confirmation checks. Both endpoints remain blocked.
Fresh authority
After the acceptance depth, the successor requests newly bound capabilities.
Reconcile first
Conflicts, loss of depth or unexpected successors can suspend access.
Preparation creates a unique durable intent and requires proof of the recipient’s proposed receiving key. Only an unsigned prepared intent can be canceled. Once a signed transition has been released, timeout, a crash or a missing mempool observation is not enough to conclude that it can never confirm later.
This creates a deliberate safety/availability trade-off. Holding both endpoints inactive during uncertainty can be inconvenient, but immediately restoring the old holder because a request “seems lost” could create competing authority when the signed transition eventually appears. Recovery must reconcile evidence rather than guess from elapsed time.
The alpha distinguishes canonical epoch from a separate local authorization fence. A chain reorganisation can move the canonical view backwards. The fence only advances, so returning to an older chain view must not resurrect previously invalidated capabilities. Unexpected succession, retirement or loss of required depth can quarantine access pending reconciliation.
Two race orders. Two different outcomes.
The most important transfer detail is the boundary between an operation already authorised and an operation trying to obtain new authority. The alpha’s receipt commitment and freeze use the same durable SQLite write-ordering boundary, including across separate coordinator instances.
| Order | Observed software result | What it does not mean |
|---|---|---|
| Freeze commits first | A new render receipt cannot commit, even if an endpoint completed its final live-state check just before the freeze. | It does not erase plaintext already present in process memory or previously displayed information. |
| Render receipt commits first | That authorization precedes freeze. Delivery of its response may complete afterward. | It is not a new post-freeze authorization, and it is not instantaneous cancellation of all in-flight output. |
| Response is lost after commit | The capability nonce remains consumed and an identical render retry is denied. | At-most-once receipt commitment does not provide exactly-once delivery to a user. |
| Failure before receipt commit | The local transaction can roll back nonce consumption. | Recovery still has to respect expiry, current ownership and the latest fence before another attempt. |
“Revoked” therefore needs a precise object: eligibility for a new capability, permission to commit a new operation, a transient display session, or information already learned. These are not interchangeable. The demonstrated software rule concerns durable authorization ordering and refusal. A future hardware display policy must separately define the cut-off for active output and test what happens to operations already committed.
This is also why no claim is made to recall copied plaintext, photographs or transcription. A digital ownership mechanism can govern future uses inside its controlled boundary; it cannot reverse every consequence of an earlier authorised disclosure.
A new device is not a new owner key.
The software implements a replacement flow when owner signing authority survives. It selects a new endpoint key, obtains proof of that key, and uses the existing freeze/succession machinery. It need not ask the lost device to cooperate. At the required confirmation depth, the old endpoint is recorded as retired for the asset.
Reorganisations can quarantine that state; they do not automatically clear the retirement decision or revive old capabilities. A reconfirmed state still needs freshly fenced authority. Replacement is therefore more than copying a file to a new reader.
The node-backed same-owner replacement demonstration uses a deliberately separate local test fixture. It does not conform to the separate experimental candidate transaction profile and should not be read as production chain replacement support. The complete device credential, custody and recovery infrastructure remains future work. Service-reconstruction tests retain ephemeral key objects; durable key storage and whole-process key recovery are not implemented.
If the sole owner signing key is lost, the present profile returns an unrecoverable-key result. Access committee shares do not magically create the missing owner signature. Future delegated, threshold or prearranged recovery would require new authority rules, proofs, dispute handling and abuse analysis; it is not already implemented by virtue of having a threshold access committee.
Real isolated-node observations. Bounded interpretation.
The opt-in bridge connects the software access gate to an isolated BSV regtest node with no public peers. It checks registered transaction bytes, expected possession script and value, chain-only unspent state and confirmation depth. It also checks that the observed chain tip did not change during the observation. Missing, ambiguous or changing evidence is a refusal condition.
The bridge uses a trusted local registry to bind logical identities to wire transaction identities. It is not SPV, a production chain-evidence service, or a Teranode integration. Separate candidate transaction-validation work does not, by itself, establish chain inclusion, current unspent status or access eligibility.
The reviewed checkpoint records 195 offline software tests, 47 main isolated-node checks, and two forced receipt/freeze orderings. These are recorded engineering results, not a public-network benchmark or a new independent rerun performed by this website. Tests include replay, stale state, expiry, quorum dropout, malformed contributions, duplicate mint/successor, cancellation/signing races, replacement, restart and reorganisation refusal.
Source status: exact-version internal engineering records were reviewed on 18 October 2026. Their code, raw transactions, logs and test material are not publicly distributed here. Read the evidence register for the dated counts, method and limitations. General technical mechanisms described here do not imply that a complete production composition has been audited.
Carry the policy into the place information becomes usable.
The software model makes the state machine, refusal cases and race semantics inspectable. A hardware implementation would have to preserve those rules while moving key use, decryption, bounded computation and rendering outside the ordinary host’s reach.
That migration is not a simple recompilation. It requires real attestation, secure provisioning, protected memory and I/O, an update/recovery policy, anti-rollback state, a defined output boundary and adversarial tests. A page, frame or record must remain a narrow operation throughout that path, not merely at the API request.
The wider system also needs scalable transaction processing and state delivery, independent service operation and explicit rights/licensing. Explore the protected-device architecture, Teranode and scalability, and the published patent landscape for the complementary layers.