Capability review · 19 September 2026
What is implemented, and what still needs proof
Digital Fabric is being developed as a programmable data and settlement foundation powered by 8DB. Node licensing is its first concrete use case. This page separates the product design, implementation evidence and service availability so you can judge the scope of a technical discussion.
The licence service
| Capability | Current evidence and limit |
|---|---|
| Purchase and issuance | Existing source has been reviewed. Payment validation, durable fulfillment and recovery are being developed and tested. A source implementation is not a production purchase offer. |
| Private bearer licences | Separating buyer records from later spending is a design requirement. The intended private issuance protocol and metadata protections still require qualification. |
| Funded wallet | The design commits existing licences to one authority with a bounded allocation budget. Source funding, concurrent claims, cancellation and recovery must preserve that budget. End-to-end qualification is outstanding. |
| Offline operation | Using an already activated node offline differs from allocating a new licence without a reachable authority. Each supported mode needs its own stated limits and evidence. |
| Third-party issuer service | Planned. Public onboarding, operational commitments, pricing and service terms are not yet available. |
A bounded database result
A separately built service consumer has exercised a draft 8DB API for atomic updates of several records, keeping original request/result data, rejection of stale updates and recovery after an orderly restart. The fixture ran outside the engine source tree at a pinned source version.
It used synthetic values and bounded batches. It did not qualify power-loss recovery, concurrent remote authorities, cloned wallets, anonymous issuance or multi-operator settlement finality. It is not yet evidence of a supported packaged service release.
What “foundation” means here
Our direction is to connect settlement with richer application storage, queries and data controls. Other blockchain systems also store state and can integrate storage and programmable transactions; a claim of universal impossibility would be inaccurate.
“Layer 0” is an analogy for foundational infrastructure at this stage. Shared security across independent networks and cross-network interoperability would need their own supported protocols and qualification.
How to read technical evidence
Implemented means an identified source version contains the mechanism. Tested means a stated check ran against a specified build and environment. Qualified means the checks required for a particular use have been completed. Available means the supported service or distribution route can actually be used under published terms.
A passing component test does not establish the whole purchase journey. A reachable gateway does not establish multi-operator finality or production licence fulfillment.
Security and cryptography
Algorithm selection, correct implementation, key custody, recovery and independent certification are different questions. The current licence-service review does not establish a combined guarantee of post-quantum protection, anonymous issuance, regulatory compliance and offline double-spend prevention.
For a technical evaluation, ask for the supported operation, version, test scope and known limits that matter to your deployment. We will distinguish source inspection from executed tests and deployed behavior.
Network observations
The network-status page reports a scoped observation when one is available. Its timestamps and failure states matter: retained historical data must not be presented as a fresh successful check.
Broader settlement work
We intend to use the licence service as a practical foundation for wider issuance and settlement. Financial products, regulated custody, general-purpose currency and institution-specific controls require separate evidence and decisions. Their appearance in a roadmap does not make them available services.