Appendix 4.2 · Information Tokenisation Proposal

Oristella Information Tokenisation Proposal

DRAFT • Decision paper and pilot specification • 20 October 2026

We propose a blockchain register that gives each information or software module a stable identity, records the rights granted to each customer and connects delivery, use and payment to the accounting system. Oristella can license the same module repeatedly while retaining its underlying rights. Each customer receives a defined entitlement, with its own price and conditions.

The central design combines one registered module, separately recorded customer licences and Oristella’s own accounting token. That token can initially be issued free of charge, with monetary pricing decided later. A token represents an identified object or entitlement; it does not make every copy a new balance sheet asset. Double-entry accounting remains in place alongside the shared rights and usage register.

Recommended first implementation

Use a permissioned EVM network based on Besu and QBFT consensus, an encrypted repository, corporate identities and controlled access. Issue ERC-721 module and licence tokens plus an Oristella ERC-20 accounting token. Pilot grants can be free; any separately paid services remain linked to invoices and bank evidence. Token pricing and wider circulation can be decided after the accounting mechanism works. [1–3, 16]

The first practical result

A user selects a module and sees its rights holder, approved versions, registered locations, active customers, permitted uses, contract prices, receipts, contributor liabilities and accounting references. Each figure can be traced to the relevant contract and event. The screen must distinguish verified records from unverified or offline deployments.

This proposal develops the supplied concept note. It is a design for a pilot, not a claim that a blockchain, marketplace or audited financial system already exists. The original document and financial workbooks are not amended. Standards and documentation were checked on 20 October 2026.

1 Problems to resolve in the concept note

Rights must be established before tokens are issued

The source proposes tokenising geological data, maps, deposit models and software. For each item, determine who owns or controls the relevant rights, who commissioned it, and whether third-party terms permit licensing, derivatives and AI training. Possession of a file is insufficient. Facts, databases, copyright, confidentiality and contractual restrictions can have different legal protection. An NFT cannot validate an unsupported ownership claim. [4]

Reproduction and disposal are different events

The source correctly identifies the economic feature of non-exclusive licensing: a customer can receive access or a copy while the supplier retains its underlying rights. This does not establish a gap that requires abandoning IFRS. Existing accounting distinguishes intangible assets, licences, services and revenue. We need finer operational records linked to that accounting. [5–7]

The blockchain cannot observe every copy

The source says illegal copying is prevented and suggests that all information movement can be tracked. Replace this with a narrower claim: the system records authorised grants, deliveries and reported use, and supports enforcement through access controls and evidence. Once a recipient obtains usable plaintext or an export, blockchain cannot prove that no additional copy exists.

A market price is not a carrying amount

The source combines identity, importance and an equivalent economic value. Separate these fields. The usefulness of a deposit model depends on location, quality, the rights granted and the buyer. A negotiated licence price, an estimated commercial value and an accounting carrying amount can differ substantially. Token scarcity alone establishes none of them.

Rewards require contracts and evidence of contribution

Pay eligible authors, owners and other agreed contributors, rather than the person who happens to mint a token. Employment terms, university agreements and commissioned work may already assign rights or compensation. Agree allocation rules before sale, record their version and resolve disputed contributions before releasing the disputed portion.

Local knowledge cannot automatically enter the central model

The source envisages a central model learning from every site. Access for operational use does not automatically include permission to train another model or disclose derived information to other customers. Store those permissions separately. Training and operator certification can support adoption; institutional or government support should remain a proposed outcome unless evidenced.

Source locations: “New accounting of information”, “Blockchain and fair reward for authors” and “Identification and market valuation of information” on page 3; the proposed Competitive Advantage wording on page 4. These observations also apply to the corresponding Russian passages.

2 Define the module before choosing the token

A tokenisation unit should be a module that can be identified, versioned, tested and licensed separately. Do not mint a token for every database row, model parameter or temporary file. Group material into useful commercial units; keep smaller components in its manifest and dependency graph.

The identity model

ModuleID remains stable throughout the module’s life. Each release receives a VersionID and an immutable manifest. Calculate a cryptographic commitment over a canonical representation of the manifest, including component digests. Never silently replace the bytes behind a recorded version. A new release receives a new commitment and an explicit predecessor link.

The complete token reference is chain ID + contract address + token ID. A token ID alone is not globally unique. An NFT identifies the registered module; the rights evidence establishes what Oristella is entitled to offer.

A version is not automatically a new accounting asset. Several versions may belong to one capitalised development project. Allocate shared costs once and identify replaced components. Bundles reference their components rather than creating duplicate underlying cost balances.

3 Tokenise rights separately from the original module

Two NFT classes for the pilot

Module NFT: one canonical registry token for each module, held by its approved corporate custodian. It links immutable release commitments and the verified rights record. Licence NFT: a separate entitlement for each customer contract line, referencing the module and the permitted version or update policy. Issuing a licence leaves the module token with its existing holder.

The legal rights holder, token-holding wallet and hosting operator are separate fields. Token ownership must not silently override the signed contract. Default licences cannot be sold, sublicensed or transferred to another organisation without the required consent. Apply restrictions to all transfer and approval paths; a front-end restriction is insufficient.

ERC-7857 is marked Final in the official register. It introduces a verifier interface for approaches such as trusted execution environments and zero-knowledge proofs. Secure off-chain storage, key management and proof verification remain implementation responsibilities. It does not prove deletion of previous copies or legal ownership. ERC-6551 is currently marked Review. A standard’s publication status is not an audit of a product built on it. [11–12]

The licence is a defined set of permissions

Record view, execute, download, modify, train, create derivatives and sublicense as separate permissions. Include the legal customer, permitted sites, territory, term, concurrency or usage allowance, exclusivity scope, update entitlement, termination and dispute rules. Pin the signed legal terms by commitment. Check new grants against overlapping exclusive rights before issuance.

4 Create the Oristella accounting token

The pilot will include a proprietary fungible token on Oristella’s permissioned blockchain. Proposed working name: Oristella Unit; the final name and symbol remain to be chosen. Use the ERC-20 interface for balances, supply and transfers, with additional issuance, permission and consumption controls. It is Oristella’s own application token, separate from the network’s technical gas unit. Operators can sponsor network transaction costs. [16]

Define the unit before assigning a price

One unit is a standard internal entitlement credit. A versioned service schedule states how many units a defined operation consumes. This schedule measures usage; a separate price schedule will state what, if anything, customers pay for units. In the free pilot, grants have no sale price or promised cash redemption. Units carry no automatic share ownership or claim to the value of a module.

The module NFT identifies the object, the licence NFT establishes permission, and the accounting-token balance limits the authorised usage budget. Access requires all applicable checks. A balance alone never grants rights to an otherwise unlicensed dataset or program.

Illustration: issue 10,000 free units; reserve 1,000 for a job; consume 800 and return 200. The customer then has 9,200 available, zero reserved and 800 consumed. Outstanding supply is 9,200. The original module and its registered versions remain intact. The spent item is the usage entitlement, not the information.

Reconcile total minted minus consumed and cancelled units to all wallet and escrow balances. Maintain grant attribution in the subledger. If different grants acquire incompatible restrictions or prices, keep their lots separate; use ERC-1155 credit classes if they are no longer interchangeable. Do not hide incompatible rights inside one fungible balance.

Free issuance is not revenue. Track service costs and any contractual obligations separately. Future paid units require a sales and performance-obligation policy; they must not retrospectively assign a dollar value to old free grants. Contributor cash remuneration continues under the agreed contract, not from an assumed market value of free tokens.

5 Value the module and price the rights

Maintain four distinct monetary views. Their separation is essential: the ledger should explain a value, not manufacture it by issuing tokens.

A repeatable pricing method

First reject modules with unresolved rights or inadequate quality for the intended use. Then assess provenance, accuracy, geographic coverage, timeliness, replacement effort, scarcity of lawful alternatives, customer benefit and delivery cost. Use actual comparable contracts where available. Otherwise set a provisional range and test it through pilot quotations.

A pricing schedule can combine a fixed access fee, the number of licensed sites or users, measured usage and separately scoped support. State each charging unit precisely. Exclusivity needs its own assessment because it can remove future licensing opportunities. An importance score helps prioritise modules; it is not a financial valuation formula.

For management appraisal, an income approach may estimate discounted, probability-weighted net licence cash flows. Include updates, hosting, contributor payments, enforcement, obsolescence and customer concentration. Model overlapping customers and substitute modules together so that the same expected income is not counted twice. This is a proposed appraisal method, not an IFRS revaluation conclusion.

Contributor allocation

For each licensed product, agree a distributable royalty pool and a set of eligible beneficiaries. Store the allocation rule with the contract version. Calculate an individual amount as eligible royalty base × pool rate × beneficiary share. The definition of the base must specify refunds, taxes, discounts, currency, collection conditions and settlement timing.

Illustration only: a USD 1,000 monthly royalty base, a 10% pool and agreed shares of 40%, 35% and 25% produce USD 40, USD 35 and USD 25. Total contributor accrual is USD 100. These shares represent a negotiated agreement, not a measured scientific contribution.

For composite products, resolve the dependency graph before invoicing. Reject cycles and duplicate beneficiary allocations; cap the total at the contracted pool. Round in currency minor units and assign any residual by a documented rule. A new module version must not rewrite allocations for earlier sales.

6 Choose a network and keep content outside it

The recommended pilot uses a permissioned Besu EVM network with QBFT consensus. Four validators provide a practical starting configuration: the pilot should continue with one unavailable validator and stop committing new blocks with two unavailable. The official quickstart is a demonstration baseline, not a production deployment. [1–2]

Permissioned does not mean confidential

Assume that validators can inspect all ordinary on-chain state and transaction metadata. Keep raw geology, source code, model weights, personal information, bank details and confidential prices outside the chain. Record opaque identifiers, status transitions and commitments. This pilot therefore relies on authorised services to attest private payment and pricing calculations; validators cannot independently validate facts they cannot see.

Encrypt content with separately managed keys. Store signed manifests and independent backups; test restoration. Salt commitments to guessable confidential records. Keep the salt and private evidence available to authorised auditors. Per-recipient encryption may change ciphertext hashes, so distinguish the canonical content commitment from each delivery envelope’s digest.

Governance and the alternative

Four nodes controlled by Oristella improve resilience but do not provide four independent authorities. A later consortium needs agreed operators, validator admission and removal, upgrade rules, cost allocation and dispute procedures. Prospective partners are not treated as committed participants.

If several organisations do not need to verify shared records independently, a signed append-only database may meet the same pilot need at lower operating cost. Preserve the same identifiers and event schema. Fabric is a further option where private data collections between organisations are the dominant requirement; its private payload and shared-hash model merits evaluation, but it is not a drop-in EVM NFT implementation. [13]

7 Connect licences to delivery and payment

Contracts and events

Principal events include ModuleRegistered, VersionReleased, LicenceIssued, UnitsGranted, UnitsReserved, UnitsConsumed, UnitsReleased, PaymentAttested, DeliveryAccepted and RoyaltyAccrued. Each carries an event ID, effective time, signatory, evidence commitment and relevant identifiers. Corrections reference the prior event and leave its history visible.

The transaction sequence

1. Agree and sign the rights, price, tax treatment and delivery criteria. Reserve any exclusive scope. Create the invoice or payment schedule and a pending entitlement.

2. For a free pilot grant, record the approved zero-price grant and its usage schedule. For paid services, the payment adapter checks bank evidence, payer, amount, currency and invoice allocation. A second role approves manual attestations. Chain confirmation proves the attestation was recorded; bank evidence proves receipt of money.

3. Activate the entitlement when the grant or contract conditions are met. Check the licence and reserve units where usage is metered. Release a recipient-specific key, a restricted download or hosted access. Collect acknowledgement against the manifest. Record disputed delivery explicitly.

4. Recognise performance and contributor accruals under the accounting policy. Record usage in signed batches with a Merkle commitment, keeping detailed logs outside the chain. Pay contributors according to the agreed settlement schedule and reconcile the bank outflow.

5. At expiry, stop further managed access and record status. An exported file cannot be remotely erased merely by expiring its NFT. Refunds, insolvency, failed delivery and disputes require contract-defined remedies and correcting records.

Avoid duplicate money and duplicate entitlements

Allocate a bank payment to invoices only once, including partial payments and refunds. Make licence issuance idempotent on contract line and grant period. Use signed requests with nonce, expiry, chain and contract binding. Fiat settlement and data delivery cannot be made a single atomic blockchain transaction: handle timeout, retry, compensation and reconciliation explicitly.

8 Keep the financial accounting intact

IFRS already addresses software, licences and related revenue. IAS 38 requires identifiable rights, recognition criteria and measurement; research costs are expensed and qualifying development may be capitalised. Minting an NFT supplies neither those criteria nor an active market. Finite-life intangibles are amortised; indefinite-life assets require support for that assessment and annual impairment testing. Continued development alone does not justify suspending amortisation. [5]

Under IFRS 15, revenue follows satisfaction of the promised performance obligations. Receiving cash, minting a licence and delivering an initial key are distinct events. Identify separate licence, hosting, updates and support obligations and allocate consideration as required. [6] A customer receiving only future access to hosted software generally receives a service; an advance payment creates a prepayment. A controlled software right can require a different analysis. [7]

Illustrative subscription entries

Assume an annual hosted-access service of USD 12,000, paid upfront and delivered evenly over twelve months. Assume Oristella acts as principal. The existing module has a USD 120,000 carrying amount before separate subsequent-measurement entries. Taxes, financing and other costs are excluded. These are explanatory amounts, not changes to the Oristella financial model.

After one month, the transaction contributes USD 11,900 net cash received, USD 11,000 remaining contract liability and USD 900 revenue less royalty expense at Oristella. The customer has USD 11,000 prepayment and USD 1,000 expense. The licence does not derecognise Oristella’s underlying module or create another USD 120,000 asset at the customer. Separate amortisation, impairment and other costs are outside this illustration.

Required accounting distinctions

An outright assignment, an exclusive licence or a separately controlled acquired right needs its own assessment. Where Oristella only arranges another owner’s supply, assess principal versus agent presentation. Intercompany records must identify both legal entities and support consolidation eliminations. The same module must not be counted again at group level simply because a subsidiary has a licence. [6, 15]

9 Show where each module is and what is owed

A balance sheet presents financial amounts. The proposed module subledger provides the operational detail behind those amounts and includes useful modules that have no recognised asset value. “Where is it?” must be answered through distinct fields rather than a single token-owner address.

Reconciliation rules

For each reporting period, reconcile the asset register to the general ledger, invoices to receivables and receipts, advance collections to contract liabilities, and contributor accruals to payables and payments. Reconcile licence events to those records without treating every event as a financial entry. A zero-value registered module must remain visible without inflating the asset total.

The connector uses a durable event queue and unique posting keys. Retries must produce the same result, not another journal. Retain the contract, invoice, bank evidence, performance record and journal ID for each transaction. Financial corrections use reversal or adjustment entries and a linked chain event; they do not overwrite closed-period history.

Illustrative lineage

Module M017 → release V003 → customer licence L104 → invoice I104 → bank receipt P209 → delivery D118 → monthly performance record R001 → journal J301 → contributor accrual A077. A second customer receives a different licence and transaction chain, both referencing M017. The module’s ownership and cost basis do not multiply.

A limit the screen must make visible

“Recorded at Customer A” means the system has a contract, delivery or deployment attestation for that location. It does not prove that no unauthorised copy exists elsewhere. Show the timestamp and evidence source. Mark an unreachable installation as unverified after the agreed interval; do not label it confirmed merely because a licence is still valid.

Keep the management view in USD if that is the chosen reporting presentation. Retain original invoice currency and any exchange-rate evidence so that a later accounting configuration can support functional-currency and statutory requirements. A display currency does not determine those requirements.

10 Protect the information and the operating model

Match access to the value and sensitivity of the module

For the most sensitive geological data and models, prefer hosted queries or controlled execution that returns only authorised results. Downloads can be watermarked and encrypted for an identified recipient, but their plaintext remains reproducible. Apply least privilege, tenant isolation, export controls, query limits and signed usage records. A hash verifies integrity against a known reference; it does not establish scientific accuracy.

Protect keys and corporate authority

Separate validator keys, contract administration, content decryption, financial approval and ordinary user access. Use managed key custody with recovery procedures. Require multiple authorised approvers for rights assignment, contract upgrades and emergency actions. Record every administrative change; use a defined notice and delay for normal upgrades and a narrowly scoped emergency pause.

Use a fresh encryption key for a new restricted release when necessary. Revocation can block future access and future keys, but cannot retract plaintext already delivered. Backup and recovery must cover keys, manifests, content and the evidence store as well as the chain. Test recovery without relying on one employee’s wallet.

Keep customer information out of unauthorised model training

Every training run needs a list of input versions and evidence of permitted use. Link resulting model versions to that record. Preserve restrictions on derivatives and redistribution. Customer isolation remains necessary even where a licence allows training. Federated learning or a trusted execution environment may reduce exposure in a later trial, but neither should be described as a universal guarantee against information leakage.

Make certification a separate credential

Use verifiable credentials for operator qualifications, with issuer, scope, expiry and revocation status. W3C Verifiable Credentials Data Model 2.0 became a Recommendation on 15 May 2025. A qualification should be bound to the person and checked by the relying organisation; selling a transferable NFT should not transfer competence. Keep credential verification separate from software licences and contributor entitlements. [14]

Resolve legal and data permissions before a live pilot

For the proposed UAE holding and Guinea operating arrangement, confirm the entities entitled to license each module, contributor assignments, customer permissions, confidentiality, geological-data restrictions, permitted hosting and cross-border transfers. The actual contracts determine the arrangement. Tokenisation does not itself create mineral rights, rights to government data or permission to export it.

The proprietary token records internal entitlement units. A later decision to sell it publicly, redeem it for cash, promise investment returns or use it for transferable third-party payments would change the product and requires a separate assessment. Those features do not follow automatically from free internal issuance.

11 How to launch the pilot

The following sequence is a proposed implementation plan. An indicative 8–12 week pilot assumes a small engineering team, available rights evidence, one accounting connector and one cooperating customer. It is not a delivery commitment or a cost estimate.

Network and application setup

1. Start from the official Besu QBFT tutorial or quickstart. Pin an assessed client release and container digests. Generate a dedicated genesis configuration and unused private chain ID. Keep test and production identities, content and keys separate. [1–2]

2. Create four validator identities in separate failure domains, plus an RPC node for applications. Set node and account permissioning. Restrict RPC through authenticated infrastructure; expose only required methods. The pilot’s corporate administrators and validator operators must be documented.

3. Deploy the module, licence, ERC-20 accounting-token and usage-escrow contracts with approved administration. Record addresses and build hashes. Issue a capped free test allocation, verify supply and then test consumption. Use synthetic or approved redacted modules until access and recovery checks pass.

4. Connect the encrypted repository, manifest signer and corporate identity service. Enforce entitlements in the actual download/API/execution path. Add a searchable index and the module subledger; do not use the blockchain as a file store or reporting database.

5. Connect the accounting sandbox and bank-evidence adapter. Exercise a free token grant through reservation, consumption and release. Separately test a paid licence, partial payment, failed delivery, refund and contributor payment before using live funds.

6. Assign named owners for rights approval, module quality, operations, payment verification and accounting. Review contract security and data leakage. Measure actual latency and operating cost before expanding the network.

7. Admit the first live module and customer only after the acceptance gate. Estimate ongoing hosting, storage, key custody, monitoring, support and independent review costs from the measured pilot. Public anchoring can be added later using periodic Merkle roots and an approved fee budget; an anchor proves a commitment, not the truth of its contents.

12 Acceptance tests and proposed wording

The pilot is successful when the evidence chain works from the original module to the customer’s rights and the final financial entry. Token minting alone is not a successful pilot.

Proposed replacement for the tokenisation paragraph

“Oristella plans to give each approved information and software module a stable identity and a verifiable record of its versions, rights and permitted uses. Customers will receive defined licences, while Oristella retains its underlying rights where the contract provides for this. Our own blockchain token will record allocated and consumed usage units; initial grants may be free, with pricing introduced later. The register will connect authorised delivery, use and payment to contributor remuneration and financial accounting. Encrypted storage and controlled access will support protection and traceability. These capabilities are proposed for staged development in Ori 2.0 and Ori 3.0.”

This wording is a proposal for review. It avoids claims that copying is impossible, that every module automatically has a reliable market value, or that blockchain replaces financial accounting. The existing presentation and website have not been changed.

13 Sources and verification basis

Official sources checked on 20 October 2026. Standards describe interfaces or accounting principles; architecture, controls, pilot scope and illustrative amounts in this paper are proposals for Oristella. No smart contracts or accounting implementation have been audited as part of this document.

[1] Besu documentation — QBFT consensus

https://docs.besu-eth.org/private-networks/how-to/configure/consensus/qbft

Validator consensus and the loss-of-quorum constraint.

[2] Besu documentation — Developer quickstart

https://docs.besu-eth.org/private-networks/tutorials/quickstart/

Four validators and an RPC node; demonstration environment, not a production recipe.

[3] ERC-721 — Non-Fungible Token Standard

https://eips.ethereum.org/EIPS/eip-721

Unique token identity and ownership/transfer interface.

[4] WIPO — Non-fungible tokens and copyright

https://www.wipo.int/en/web/wipo-magazine/articles/non-fungible-tokens-nfts-and-copyright-42365

Distinguishes tokens from underlying copyright and identifies unsupported ownership claims.

[5] IFRS Foundation — IAS 38 Intangible Assets

https://www.ifrs.org/issued-standards/list-of-standards/ias-38-intangible-assets/

Recognition, cost, development expenditure, useful lives and subsequent measurement.

[6] IFRS Foundation — IFRS 15 Revenue from Contracts with Customers

https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/

Performance obligations, allocation and timing of revenue. Principal/agent assessment requires the applicable detailed guidance.

[7] IFRIC Update March 2019 — Customer access to cloud software

https://www.ifrs.org/news-and-events/updates/ifric/2019/ifric-update-march-2019/

Agenda decision on software control, service access and customer prepayments.

[8] ERC-1155 — Multi Token Standard

https://eips.ethereum.org/EIPS/eip-1155

Multiple token types and quantities within one contract.

14 Additional sources and document control

[9] ERC-4907 — Rental NFT

https://eips.ethereum.org/EIPS/eip-4907

Temporary user role and expiry for a token.

[10] ERC-2981 — NFT Royalty Standard

https://eips.ethereum.org/EIPS/eip-2981

Royalty signalling; the interface does not mandate payment.

[11] ERC-7857 — AI Agents NFT with Private Metadata

https://eips.ethereum.org/EIPS/eip-7857

Status Final; private metadata, verifier interfaces and implementation security requirements.

[12] ERC-6551 — Non-fungible Token Bound Accounts

https://eips.ethereum.org/EIPS/eip-6551

Status Review; accounts associated with NFT ownership.

[13] Hyperledger Fabric — Private data

https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html

Selective private-data sharing and verification against shared hashes.

[14] W3C — Verifiable Credentials Data Model 2.0

https://www.w3.org/TR/vc-data-model-2.0/

W3C Recommendation of 15 May 2025; structured credentials and verification model.

[15] IFRS Foundation — IFRS 10 Consolidated Financial Statements

https://www.ifrs.org/issued-standards/list-of-standards/ifrs-10-consolidated-financial-statements/

Consolidated presentation of a parent and controlled entities as one economic entity.

[16] ERC-20 — Token Standard

https://eips.ethereum.org/EIPS/eip-20

Fungible token interface: supply, balances, transfers and allowances. Issuance and usage rules are application design decisions.

Source document

Oristella _tokenisation of information.docx • supplied desktop file • 4 pages • dated 20 October 2026. Reviewed from a read-only copy. The bilingual concept and suggested presentation wording were treated as source material, not as instructions to publish changes.

Source SHA-256 6c896a27ae9f017c92c2e8add49a2718001c8bb75951fd540c63502e57d4d6e1

Revision 1 • Incorporates the instruction to include an Oristella accounting token, initially issued free with pricing decided later. Proposed system name: Oristella Information and Software Rights Ledger. No network deployed, funds transferred or existing financial model changed.

← Return to main appendix