Digital Fabric · Powered by 8DB · In development

Bring data, rights and settlement together

We're building a programmable foundation for issuing and transferring digital rights and value, with the application data and controls those transactions need.

8DB supplies the database foundation. Digital Fabric is the service built on it. Our first proving ground is our own node licences: buy a licence, give it to another person, or commit several to a wallet that controls their allocation.

Explore the first use case · Discuss your settlement use case

The broader aim is infrastructure other products can use, from software permissions to settlement applications. Each use needs a defined trust model and evidence that it works.

A transaction has more to it than a transfer

A useful application also needs to know what a right enables, who may exercise it, which records support the decision and what happened if a response was lost.

Our aim is to bring those concerns into a consistent data and settlement design. That could reduce the separate records and reconciliation work an application needs while giving owners control over private information.

Blockchain systems also store data and support programmable transactions. The question we're testing is how much of an application's storage, permissions, queries and settlement can work coherently through 8DB's shared foundation.

First use case: licences people can hold and give

For 8DB, the intended free tier provides local storage and search. A one-time licence is planned for mesh capability on each node. An unused licence can be given to another person; permission to join a particular mesh remains separate.

We're also developing a funded wallet. Buy ten licences, activate one node and commit nine to one wallet authority. Those nine are backed by the original licences, which cannot also be spent independently.

The privacy goal is to separate the person who paid from the person who later uses a licence. Recovery and operational records must respect that separation. This remains part of the qualification work, alongside duplicate-spend protection and recovery after interrupted requests.

Purchase channels, platforms and final prices will be published before sales open. No licences are offered for sale on this page.

How the 8DB licence model is intended to work

Design in development. Purchase channels, final pricing and supported recovery paths will be confirmed before sales open.

Start with a free local app

The planned free tier covers basic local storage and search. Mesh creation, joining and synchronization require the appropriate paid node capability. A licence to use those capabilities is separate from permission to join a particular mesh or read its data.

Buy for yourself or someone else

The intended one-time purchase covers one node/device installation. You can apply an unused licence to your own node or give it to another person. It is not an unlimited-device purchase.

A QR code and a manual code are ways to pass the same claim. Copying that claim does not create additional licences. Acceptance needs a confirmed result from the responsible authority; a message being sent is not proof that activation has completed.

Store purchases must follow the applicable store's rights, including restoration. The exact Apple purchase and redemption routes are still being resolved.

Hold several licences in a wallet

The planned bulk flow is simple to describe: buy ten, use one, and commit nine to a wallet. That wallet's authority then controls those nine allocations.

The distinction matters. Loading the wallet commits the original licences, so they cannot also be spent elsewhere. An available allocation, a reserved claim and an issued activation have different states. An old backup cannot reset those states or restore spent capacity.

A personal wallet remains separate from a corporate mesh unless you explicitly choose the relevant authority arrangement.

Understand what can work offline

An already activated node can use its supported offline capabilities. Allocating another licence is a separate operation.

A local wallet authority may eventually support allocation without public internet access. That still requires a qualified way to reach the authority and prevent conflicting allocations. A copied claim alone cannot establish whether somebody else has already accepted it.

When the outcome is unknown, the app should let you keep the request and check it later. It should not show a completed activation or restored balance without confirmation.

Keep recovery material safe

The intended recovery process retrieves the original result. It does not issue a fresh licence because a response was lost.

A purchase receipt may identify the buyer, but the buyer may have given the licence away. Recovery therefore needs the appropriate private proof. Losing a wallet key or the only usable recovery copy can prevent recovery; a support account cannot simply replace the spending authority.

Restoring a backup may require checking the current history before allocating more licences. Removing local files does not cancel pending transfers, recall issued licences or refund a payment.

Know what payment includes

Before any sale, the offer will identify the licence class, number of nodes, price, currency, taxes, channel and material limits. Optional hosted relay or other services would have their own clearly stated terms and charges.

Refunds follow the selling channel and applicable consumer rights. Refunding a payment and reversing an anonymous allocation are different operations. No sale is offered by this explanatory page.

Ask about this model · Check capability status

Build the foundation through real use

Using Digital Fabric for our own licensing exercises the same problems other issuers face: recording an operation reliably, conserving issued rights, recovering its original result and handling failures without inventing another balance.

A draft 8DB interface has been exercised by a separate service consumer for atomic updates and recovery after an orderly restart. That is a bounded implementation result. Multi-operator finality, private issuance, disconnected allocation and production service availability require further qualification.

See capability and evidence status

Where this can lead

The longer-term direction includes other issuers, privately operated deployments and financial settlement applications. These are development directions with additional technical, operational and legal requirements.

Tell us what you want to issue, what must stay private, who can authorize a transfer and how your system should behave when participants disconnect. That gives us a useful starting point for a technical discussion.

Discuss your use case · Network observations