Distributed Ledger Network
Network/governance context for tokens and smart contracts
Bundle → Layer → Finding → Questions Filled
3 bundles · 3 layers · 5 findings · 10 questions
Network identity and protocol Which network and how it agrees on state.
Chain and protocol
Chain identifier, genesis, consensus and protocol version.
Network identity
The network is identified by its chain identifier and genesis, distinct from forks and test networks.
- Which chain identifier and genesis block identify the network?
- Is this the main network, a test network or a fork?
Consensus
The consensus mechanism and finality behaviour.
- Which consensus mechanism does the network use?
- When is a transaction considered final on this network?
Participation and governance Who runs it and who decides on changes.
Participants and governance
Node operators, validators and protocol change process.
Validator set
Who validates blocks and how they are admitted.
- Is participation permissionless or permissioned?
- Who are the validators, and how concentrated is control?
Protocol change
How upgrades are proposed, decided and activated.
- How are protocol upgrades proposed and decided?
- Which upgrades or forks happened, and when?
Compliance and risk Legal status and operational risk.
Regulatory context
Applicable regulation and known incidents.
Status and incidents
Regulatory status and recorded outages, attacks or reorganisations.
- Which regulatory regimes apply to services built on the network?
- Which outages, attacks or chain reorganisations have been recorded?
Classifiers Filled
- Family
- World Models
- Category
- Information and virtual systems
- Entry kind
- standalone-mm
- Navigation path
- NAV.INF.VRT.DLT
- Domain
- INF.VRT.DLT
- Industry
- Cross-industry
- Tags
- distributedledgernetworkinf.vrt.dlt
What it is Filled
A distributed ledger network is a network of nodes that maintains a shared, replicated ledger under a consensus protocol, such as a public blockchain or a permissioned ledger operated by a consortium. The subject is the network with its protocol, participants and governance, the context in which tokens and smart contracts live; the tokens, contracts and individual transactions are described in their own models.
Why it exists Filled
Network/governance context for tokens and smart contracts
Distinguishing features Filled
- It is the network and its governance, not a token, smart contract or transaction on it.
- Its identity rests on a chain identifier and genesis, so forks become separate networks.
- Governance spans on-chain rules and off-chain decisions by developers, validators and consortia.
- Distinct from a conventional ledger kept by one accountable party.
What robots and AI may and may not do Filled
Must not
- Sign or submit transactions without explicit human authorisation.
- Handle or expose private keys or seed phrases.
- Give personalised investment advice about network tokens.
- Treat a test network or fork as the main network.
- Help circumvent sanctions or anti-money-laundering controls.
Only with a human decision
- Any transaction that moves value.
- Operating or changing a validator or node.
- Voting on governance or protocol upgrade proposals.
May
- Read public ledger data and network parameters.
- Report the chain identifier, consensus and finality of a network.
- Monitor network health, upgrades and incidents.
Moral aspects Filled
- Immutability means errors and personal data written to the ledger may never be removed.
- Concentrated validator control can undermine the decentralisation users rely on.
- Energy use and financial risk vary widely between networks and affect society beyond users.
Who is affected
- Users holding assets on the network
- Node operators and validators
- Developers of applications on the network
- Regulators and the wider public
Owners Filled
Steward
The foundation, consortium or developer community that maintains the protocol, together with the validators who operate the network.
Master systems
- Protocol specification repository
- Chain registry
- Block explorer
Links to other meta-models Filled
parent
- WM-SFT-002
What else AI and robots need to interact with it Filled
Identity and identifiers required Filled
- A network is identified by its chain identifier, for example under CAIP-2, together with its genesis block hash.
- Nodes and validators are identified by their network keys or addresses.
Direct properties not applicable Not applicable
Not applicable
A distributed ledger network is a digital system; its parameters are recorded as protocol settings, not measured physical properties.
Recognition optional Filled
- A network is recognised by its chain identifier, genesis, client software and public endpoints.
- Often confused with its native token, with a test network or with a fork sharing the same name.
Capabilities and actions required Filled
- Transactions can be validated, ordered and finalised by consensus.
- The full history can be replayed and verified by any full node.
- The protocol can be upgraded through its governance process.
Hazards and failure modes required Filled
- Consensus attacks or chain reorganisations that reverse transactions.
- Loss of funds through key compromise.
- Permanent exposure of personal data written to the ledger.
Standards and interfaces required Filled
- CAIP chain identifiers for cross-network references.
- JSON-RPC node interfaces exposed by client software.
- ISO 22739 vocabulary for blockchain and distributed ledger technologies.
Context of use required Filled
- Used for crypto-assets, tokenised assets, supply chain tracing and shared registers.
- Services built on networks fall under crypto-asset and anti-money-laundering regulation such as MiCA.
Sources Filled
- ISO 22739 Blockchain and distributed ledger technologies - Vocabulary (ISO)
- Regulation (EU) 2023/1114 on markets in crypto-assets, MiCA (European Union)
- FATF Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers (Financial Action Task Force)
Open questions
- Planned model: boundary questions, research and every section remain to be written.
Machine files
Provenance
planned (registry candidate) · todo
Built from: models/runtime-index.json, ver-cy/world-models/card-supplements/wm-vrt-010-distributed-ledger-network.json
Planned entry, hidden from the catalogue until researched.