Ownership has a lifecycle, not just a first transaction.
A useful possession system must create assets, recognise control, process transfers, handle replacement and recover from interruption. At a small scale, a single test node can exercise the rules. At a large scale, transaction processing, observation, storage and application services have to keep up without weakening those rules.
Teranode is relevant because it changes how BSV transaction-processing work can be organised and deployed. INTEGYRS intends to evaluate that infrastructure as a future path for large numbers of assets and owners. The current alpha uses an isolated SV Node 1.2.3 regtest environment. It has not demonstrated Teranode integration or public-network settlement.
The strategic connection is straightforward: device-level control needs an economical, dependable way to recognise changes of authority across many devices. Scalable settlement infrastructure can support that coordination. It cannot, on its own, stop an operating system reading a decrypted page or prove that a device has cleared a protected buffer. Ledger scale and endpoint security solve different parts of the system.
Scale particular jobs instead of one undifferentiated process.
Teranode divides transaction processing into services for propagation, validation, subtree handling, block assembly, blockchain/chain-state management and persistence. This lets operators allocate resources to particular workloads and scale selected services across machines.
Not every component is horizontally replicated in the same way. The current official architecture identifies Block Assembly and Blockchain as single-instance services. These stateful responsibilities, the storage layer and the network remain part of capacity planning. More validators are useful only if the surrounding system can supply data, coordinate updates and persist the results.
Propagation
Move transaction information between cooperating services and peers.
Validation
Check transactions and state against applicable rules.
Subtrees
Organise transaction references and validation work before final block assembly.
UTXO / persistence
Spend tracking, concurrent updates, database throughput and recovery.
Block Assembly
Assemble the selected transaction structure into candidate blocks.
Blockchain
Manage the chain-facing state and related coordination.
Primary source: Teranode microservices architecture. The diagram is a simplified explanation; it does not imply that every box is independently scalable or that INTEGYRS has deployed them.
Organise work early. Do not remove the checks.
Block arrival creates a difficult coordination point if a node encounters a large amount of completely new work at once. Teranode’s transaction lifecycle spreads validation and transaction-state work across the lifecycle. Subtrees group transaction references into manageable structures that can be propagated and validated before a final block is assembled.
This can reduce the concentration of previously unseen work at block arrival. It does not mean a short subtree reference replaces validation of the transactions it represents. A receiving system still needs the missing transaction data, correct relationships, state checks and applicable validation results.
For INTEGYRS, the relevant outcome is coherent authority state. A transaction accepted into an intermediate processing stage is not automatically a confirmed possession successor. Application policy must distinguish submission, mempool visibility, chain inclusion, confirmation depth and current unspent status.
Primary source: Teranode transaction lifecycle. Application acceptance and access-policy interpretation remain INTEGYRS design responsibilities.
A faster pipeline still needs a truthful current view.
UTXO means unspent transaction output. Tracking which outputs remain unspent is central to recognising whether a previously identified possession has been spent onward. Teranode’s UTXO store supports transaction-state operations and coordination among validators. Its capacity depends on workload, concurrent updates, record size, consistency and the storage system behind it.
Adding processing machines without sufficient database or network capacity moves the bottleneck. Recovery also matters: an operator must know how a node restores consistent state after an interruption, how much history it retains, and how dependent application services handle unavailable or conflicting observations.
For a possession application, a signed state answer must be both authentic and meaningful for the request. It needs an accepted chain view, current-state semantics, challenge binding, defined age limits and clear handling of reorganisations. A signature authenticates who supplied the answer; it does not independently make that answer complete or current.
Primary sources: Teranode UTXO store and the official Teranode deployment guide, which warns that storage performance can constrain its databases. These operational considerations must be included in a future integration benchmark.
A benchmark is a workload and an environment.
The Teranode project’s published test history reports a May 2024 milestone exceeding one million transactions per second across six geographically distributed test nodes for two weeks. That is publisher-reported test-network evidence. It is not an INTEGYRS benchmark, a guarantee of production throughput or a promise of application response time.
To interpret any throughput number, ask what was counted, which transaction sizes and scripts were used, how long the run lasted, which failures occurred, what was persisted, and what hardware/network/database configuration produced the result. Sustained operation, tail latency and recovery tell a different story from a short peak.
Illustrative arithmetic, not a measured workload: 1,000,000 transactions per second × an assumed 500 bytes each = 500 MB/s, approximately 4 Gbit/s of raw transaction data. One full day at that rate is 43.2 TB before indexes, proofs, replication, backups and protocol overhead. Different transaction sizes and retention policies change the result.
The arithmetic explains why high throughput is a full-system engineering question. Compact references can improve coordination, but they do not make underlying data, validation, storage or recovery disappear. A useful commercial estimate also needs actual transaction fees and infrastructure costs rather than an assumed zero cost.
Reported milestone: Official Teranode testing history. The arithmetic above is an explicit hypothetical illustration, separate from the publisher’s test result.
A page turn is not automatically a chain transaction.
| Workload | What it measures | Main constraints |
|---|---|---|
| Settlement | Creation, transfer and other events explicitly committed to the ledger. | Transaction validation, propagation, confirmation policy, chain state, fees and storage. |
| Observation | Fresh evidence consumed by an access decision. | Observer latency, authentication, consistency, availability and privacy. |
| Authorisation | Eligibility checks and cryptographic contributions for an operation. | Committee capacity, proof verification, replay state, custody and failure handling. |
| Protected use | Page layout, frame decode, bounded computation and output. | Protected memory, device performance, display path, energy, secure I/O and retirement. |
The final product design must specify which events belong on-chain and which are authenticated off-chain or enforced locally. It should not assume a blockchain transaction for every display frame merely because the content is divided into frames. Nor should an off-chain optimization silently remove the fresh-ownership check that gives transfer its meaning.
As a hypothetical sizing exercise, one million active readers requesting a new unit every 20 seconds would produce 50,000 unit requests per second. A design making two observations per request would need 100,000 observation responses per second before retries. This is arithmetic about assumed usage, not a target, measured load or commitment to that particular architecture.
Caching, batching, prefetch and leases can reduce repeated work, but change the freshness window or the amount of content authorised in advance. Those trade-offs should be explicit. A bounded protected prefetch window may be reasonable; an unbounded full-work plaintext cache would contradict the intended device boundary.
Proof size, freshness and availability are different problems.
Later development is planned to investigate off-chain proofs and verification mechanisms. A proof of transaction inclusion can show that specified data belongs to a particular authenticated block structure. It does not, by itself, show that the recognised output remains unspent now, that no relevant later event exists, or that an isolated device has the current chain view.
A future verifier therefore needs a complete evidence policy: accepted headers or state authority, chain selection, freshness, conflicts, spending status, recipient binding and refusal when evidence is unavailable. The alpha does not implement a production off-chain-proof or SPV integration.
Offline access is a separate research question. A disconnected device cannot immediately learn that ownership changed elsewhere. Bounded offline leases, restrictions on transfer while an offline entitlement remains outstanding, and later reconciliation are possible policy directions, each with a declared risk window. Secure time and rollback-resistant state would still be necessary.
The current alpha requires live authenticated observations. Neither a scalable node nor a small proof converts it into an offline reader. Copyright management is another separate layer and is also outside the current alpha.
Measure completed operations and failure behavior.
A Teranode integration should be version-pinned and tested with representative asset operations. The results should show the complete route from a submitted ownership transition to an accepted observation and a correct access decision, rather than borrow an infrastructure headline.
- Workload: transaction sizes and script patterns, assets, simultaneous readers, unit sizes, transfer frequency and the balance of successful and refused operations.
- Latency: median and tail submission, confirmation, observation, authorisation and page/frame response times, reported separately.
- Correctness: duplicate requests, conflicting successors, reorganisations, stale observations, interrupted transfers and recipient replacement.
- Availability: custody-node dropout, observer unavailability, database pressure, network partitions, restart and recovery duration.
- Security: no reduction of thresholds or freshness requirements just to sustain an attractive throughput number.
- Cost: hardware, networking, storage, service operation, support, attestation and recovery, with assumptions and measurement dates.
- Privacy: linkable possession histories, request patterns and recovery metadata, plus the effect of caching or shared observation services.
Teranode matters because it offers an infrastructure path worth evaluating for a large possession system. The product only becomes credible when that capacity is joined to correct authority transitions, practical operating costs and a protected endpoint that enforces the intended use.