This section introduces the foundational concepts that underpin the Constellation Network. It covers the network's layered architecture, consensus model, token standards, fee structures, and the role of metagraphs within the broader ecosystem. Whether you're building a decentralized application, running a validator, or integrating with the network, these articles will help you understand how the core components fit together.

For guidance on building and deploying metagraphs, see therapid development resources available in the .

Developer support is available on .

Overview

Constellation Network uses a modular, horizontally scalable architecture designed to support high-throughput applications, verifiable data, and decentralized value transfer. At the heart of the network is the Global Layer 0 (gL0)—known as the Hypergraph—which acts as the final consensus layer and source of truth for all activity across the network.

The Hypergraph aggregates data from multiple sources, including the DAG L1, where native DAG token transactions are validated and structured into blocks using a directed acyclic graph (DAG) model. Once validated, these blocks are submitted to the global L0 for final inclusion in the network’s canonical ledger.

Constellation also supports modular application layers called metagraphs—independent subnets that define their own logic, tokens, and data structures. Each metagraph includes:

• Currency L1: Validates transactions involving its native L0 token.

• Data L1: Validates domain-specific custom data updates.

• Metagraph L0: Packages validated L1 transactions into metagraph snapshots, which represent the metagraph’s finalized state.

Metagraph snapshots are submitted to the Global L0 (Hypergraph) alongside DAG L1 blocks. After undergoing a final round of validation, all accepted data is recorded into a global snapshot, which serves as the immutable, globally recognized record of network state.

This layered architecture allows Constellation to maintain global consistency while supporting decentralized, scalable execution across a diverse set of applications. By anchoring all activity to the Hypergraph, the network ensures both flexibility at the edge and strong consensus at the core.

Metagraphs are modular, application-specific components of the Constellation Network. Each metagraph is composed of a Layer 0 (L0) and one or more Layer 1 (L1) layers. Together, these layers manage the ingestion, validation, consensus, and finalization of application data and token transactions within the metagraph.

• L1 Layers are responsible for ingesting data or transactions, performing initial validation, and reaching consensus using a DAG-based consensus algorithm.

• L0 Layer performs final validation, runs majority-based consensus, and packages validated blocks from L1 layers into metagraph snapshots—the core unit of state on a metagraph.

• Snapshots are submitted from the metagraph L0 to the Global L0 (Hypergraph) for inclusion in the global snapshot chain.

Each layer consists of a cluster of 3 or more nodes. Nodes within a layer communicate over secure HTTP APIs with source-signed messages. Cross-layer communication (e.g., L1 to L0) also uses HTTP with additional security measures to ensure integrity and authentication.

Also referred to as the Currency L0 layer, this is the final consensus and validation layer of the metagraph. It:

• Aggregates blocks from L1 layers

• Forms the metagraph snapshot chain

• Submits finalized snapshots to the Global L0 (Hypergraph)

The metagraph’s L0 snapshot chain is independent of the global snapshot chain but is periodically synchronized with it through snapshot submission.

A DAG-based L1 layer dedicated to L0 token transactions. It:

• Validates transactions (signatures, balances, sender addresses)

• Applies any custom logic defined by the metagraph

• Forms blocks from valid transactions

• Runs graph-based consensus over blocks

A DAG-based L1 layer for domain-specific custom data updates. It:

• Validates and decodes application-specific data

• Verifies signatures and runs custom validation logic

• Forms blocks of valid data

• Runs DAG-based consensus

The Hypergraph is the network-wide Layer 0 consensus layer. It:

• Validates and finalizes metagraph snapshots

• Validates and finalizes DAG L1 blocks

• Aggregates them into global snapshots

• Maintains the canonical record of all activity across DAG L1 and metagraphs

Once a metagraph snapshot is accepted into a global snapshot, it is considered finalized and recorded on-chain.

Constellation’s metagraph architecture is optimized for both horizontal and vertical scaling:

L1 layers benefit from distributed consensus and can scale out as needed to support high data volumes. L0 layers must reach majority consensus and require synchronized participation, so their performance scales vertically rather than horizontally.

Constellation’s architecture combines localized processing with global consensus to support secure, scalable, and application-specific blockchain infrastructure. Metagraphs operate independently with their own validation and consensus layers, while the Hypergraph serves as the unifying Layer 0 that finalizes state across the entire network. By coordinating all finalized activity into global snapshots, Constellation ensures a consistent, tamper-proof ledger—while enabling parallel execution and innovation at the edge of the network.

The Tessellation project is the core protocol implementation of the Constellation Network. It defines the logic and infrastructure that powers the Hypergraph—the global Layer 0 responsible for consensus, snapshot processing, and coordination across all metagraphs. Tessellation also includes the foundational components needed to build, run, and connect metagraphs to the network.

As the lowest-level implementation of the network, Tessellation acts as the foundation for higher-level tooling, including the , which simplifies metagraph development. While most developers will interact primarily with Euclid, Tessellation provides the underlying services, protocols, and consensus mechanics that enable scalable, decentralized applications to operate securely on the Constellation Network.

Overview

Constellation Network accounts are identified by cryptographic addresses that serve as public identifiers for transactions on the network. These addresses are used across both the Hypergraph (DAG) and metagraphs (L0 tokens), ensuring a unified identity model across the entire ecosystem.

Each account is secured through asymmetric cryptography, relying on a Key Trio consisting of a private key, public key, and address.

The Key Trio

In the Constellation Network, accounts are composed of a key trio consisting of the private key, public key, and an address.

• Private key: The private key is a highly confidential piece of information that plays a crucial role in authenticating an address to the network. With the private key, you can execute sensitive actions like signing messages or sending transactions.

• Public key: The public key serves as a unique identifier for nodes on the network and is derived from the private key. It is crucial for establishing trust relationships between nodes, enabling secure communication, and verifying digital signatures.

• Address: The address is the public-facing component of the Key Trio and represents a public wallet address for receiving payments or other digital transactions. It can be derived from either the private or public key and is widely used for peer-to-peer transactions. Sharing your address with others enables them to send you payments while keeping your private key confidential.

Addresses consist of 40 characters divided into three parts.

• Prefix: the characters “DAG”.

• Check digit: A single decimal calculated from the digits in the Hash.

• Hash: The hash of the first 36 characters of an account public key.

The Check Digit is computed by taking the sum of all digit characters in the Hash. If the sum is greater than 9, the sum is reduced to a single digit by taking the remainder of the sum divided by 9.

In the address DAG5poQ31KFjikEgLoqnf9CQR2KVYv3pfxV5NQZY the Check Digit can be calculated in the following way:

Thus, the Check Digit is 5.

The Hash can be derived from the public key in hex format in the following way:

The address is constructed of the three components concatenated together:

Constellation Network supports ECDSA signatures on secp256k1.

To sign messages, a sha512 hash of the message is signed with the private key.

Constellation Network’s token model goes beyond simple value transfer by enabling a set of advanced token features that support staking, delegation, fee logic, and smart interactions between wallets, metagraphs, and the Hypergraph. These capabilities are available to both the native DAG token and any L0 token implemented using the Euclid SDK’s Currency L1 module.

Delegated Spending

One of the most powerful tools in Constellation’s token system is the delegated spending mechanism, made possible through the AllowSpend and SpendTransaction types. These allow a wallet to pre-authorize another entity—such as a metagraph or another user—to spend a specific amount of tokens on its behalf, under certain conditions.

AllowSpends are single-use and time-limited, providing a safe and controlled alternative to open-ended token approvals common in other ecosystems. This enables use cases such as:

• Atomic token swaps between parties or metagraphs

• Auction or bidding systems

• Metagraph-managed multi-sig wallets

• E-commerce workflows with conditional payment fulfillment

SpendTransactions are submitted by the delegate (typically a metagraph) once the specified conditions are met, consuming the AllowSpend and triggering the associated transfer.

The network supports locking tokens via TokenLock transactions, which remove funds from a wallet’s spendable balance for a defined duration or until a specific unlocking condition is met. Locked tokens remain tied to the wallet and cannot be transferred, adding security without moving tokens into a third-party contract.

Token locking is used for:

• Node collateral staking

• Delegated staking participation

• Governance requirements

• Time-based vesting or escrow models

Locks can be unlocked automatically based on duration or manually by the metagraph or Hypergraph when conditions are met. All unlocks are recorded on-chain via TokenUnlock system transactions.

FeeTransactions are a special transaction type used to associate a payment with a piece of custom data submitted to a metagraph. When a user sends an application-specific DataUpdate (such as a document, event, or sensor reading), they include a FeeTransaction alongside it. This transaction contains:

• A payment amount in the metagraph’s L0 token

• A hash reference to the associated data

• A signature from the sender’s wallet

This structure allows metagraphs to enforce pay-per-update models while maintaining data privacy and minimizing on-chain storage. FeeTransactions are essential for use cases where data ingestion, validation, or storage is tied to verifiable utility and compensation.

Metagraphs can also define custom fee logic for L0 token transfers on their Currency L1 layer. Unlike FeeTransactions, which pair with data, these fees apply to standard token transfers and can be customized to fit a metagraph’s specific business model.

Using the Euclid SDK, developers can implement:

• Flat or percentage-based transfer fees

• Fee exemptions for specific addresses

• Dynamic fees based on transfer size or other logic

This gives each metagraph the flexibility to define how value flows through their ecosystem, enabling sustainable and purposeful token economies that align with the goals of the project.

These advanced features allow developers to design flexible, expressive token economies without deploying external smart contracts or exposing users to unnecessary risk. Together, they form the foundation for secure, utility-driven systems that can scale across use cases—from DeFi to enterprise operations and beyond.

On the Hypergraph, snapshots serve as the core unit of state progression, replacing the traditional blockchain model of sequential blocks. Instead of processing transactions individually within a single chain, the network allows multiple L1 layers—such as DAG L1 and Currency L1—to create blocks independently in parallel. These blocks are then submitted to the L0 layer (Hypergraph/metagraph L0), where they are validated and aggregated into snapshots. Each snapshot finalizes a set of blocks, creating a cohesive and secure record of network activity.

This snapshot-based approach enables high throughput by allowing concurrent execution of L1 blocks while maintaining strong security guarantees through the Hypergraph’s global finalization process. Snapshots provide a scalable way to track and verify state changes across both the Hypergraph and metagraphs.

A snapshot in Constellation Network serves a function similar to blocks in other blockchains, but with key differences. Rather than containing individual transactions, a snapshot finalizes a collection of validated L1 blocks. These snapshots form a cryptographically linked chain that represents the history of the network’s state.

Each Global Snapshot records the Merkle root of all finalized transactions, along with references to previous snapshots to maintain continuity. It also includes any metagraph snapshots that have been submitted to the Hypergraph, ensuring that metagraph state is secured at the L0 level. Once finalized, a snapshot is immutable and verifiable, creating a reliable source of truth for all network participants.

The L0 Token Standard, also referred to as the Metagraph Token Standard, is Constellation Network’s specification for currency tokens across its modular, multi-layered architecture. It defines a shared interface and core functionality for all value-transferring tokens on the network—spanning both DAG, the native asset of the protocol, and L0 tokens, which are custom tokens issued by metagraphs.

At its core, the L0 Token Standard provides the structural and transactional foundation for interoperability between metagraphs, as well as with external systems such as wallets, exchanges, and APIs. Whether a user is transacting in DAG or an L0 token issued by a metagraph, the experience and underlying mechanics are consistent and composable, allowing for straightforward integration across the ecosystem.

The L0 Token Standard supports a growing set of advanced transaction types, which as of the Tessellation V3 release include:

• Currency transfers: Basic send and receive operations between wallets.

Metagraphs are modular, application-specific components of the Constellation Network. Each metagraph operates as an independent subnet with its own state, logic, and validation rules, while anchoring final results to the Hypergraph—the network’s global Layer 0 consensus layer. Metagraphs allow developers to build and deploy their own infrastructure on top of the Constellation protocol, leveraging its consensus and security model while maintaining control over application-level behavior.

A metagraph is composed of one or more Layer 1 (L1) components and a single Layer 0 (L0) component. Each layer forms a cluster of validator nodes that run consensus and communicate with other layers via signed HTTP requests. The internal architecture of a metagraph determines how it processes transactions and data, how its native token is used, and how it contributes to the global state of the network.

Use Cases and Applications

Metagraphs are designed to support application-specific logic and infrastructure, making them suitable for a wide variety of use cases that require trusted data processing, verifiable value transfer, or domain-specific rules. Because metagraphs define their own transaction types, token logic, and data validation models, they can be tailored to meet the operational, regulatory, and business needs of specific sectors.

Some common categories of metagraph use include:

• Digital Asset Infrastructure: Metagraphs can host their own L0 tokens with custom economic models, fee logic, and staking mechanisms. Projects use metagraphs to issue tokens that support in-app economies, network access rights, or incentivization schemes. Built-in support for features like delegated spending and token locks make them useful for secure, auditable token operations.

• Verifiable Data Pipelines: Metagraphs with Data L1 layers can ingest, validate, and notarize structured or semi-structured data. This is particularly useful for use cases that involve compliance, audit trails, or timestamped records—such as law enforcement logs, financial data submissions, healthcare attestations, or supply chain documentation.

• Public Sector and Critical Infrastructure: Some metagraphs are built to ingest mission-critical data from public safety or emergency response systems. For example, a metagraph might notarize data streams from field devices, vehicles, or sensors, ensuring that the resulting records are tamper-proof and can be referenced in legal or operational audits.

• Cross-Network Coordination: Because all metagraphs anchor their state to the global L0 (Hypergraph), they can coordinate with one another through globally ordered state updates. This makes it possible to build workflows that span multiple metagraphs—for example, a token swap between two projects or a verification system that combines identity credentials with asset ownership data.

• Enterprise Data Services: Organizations can use metagraphs to enforce internal rules on how business data is validated, stored, and accessed. This allows enterprises to build blockchain-based backends for analytics, reporting, or service metering—without exposing their full infrastructure to the public network.

Ultimately, metagraphs provide a framework for building verifiable systems where each application defines its own boundaries and logic, while still benefiting from a shared network for consensus and security. As more use cases emerge, metagraph design patterns continue to evolve—ranging from lightweight validators for narrow use cases to complex multi-layered systems with rich token economies and data coordination mechanisms.

Developers build metagraphs using the , a modular framework for defining metagraph behavior. The SDK provides tools for:

• Creating custom token types

• Defining transaction and data validation logic

• Managing metagraph state and snapshot production

• Signing and submitting snapshots to the Hypergraph

Metagraphs are written in Scala and deployed as services that run continuously and participate in consensus. Developers implement one or more node types—L1 L0 nodes—and define the application’s structure through configuration and SDK extension points. Most projects begin by extending the SDK’s base CurrencyL1App and CurrencyL0App classes and integrating with the provided APIs.

In addition to the core services, metagraph developers often implement external APIs, indexing layers, or front-end applications that interact with the metagraph’s state or trigger transactions.

After development, metagraphs are deployed as independent clusters of validator nodes, typically with three or more nodes per layer. These nodes handle transaction ingestion, consensus, snapshot creation, and submission to the Hypergraph. Developers provision the infrastructure, configure networking and keys, and maintain uptime across the L1 and L0 layers.

Metagraph developers are responsible for managing their network, including:

• Launching and configuring validator clusters

• Monitoring node health and snapshot progress

• Upgrading logic as application needs evolve

The provides built-in tools for initializing clusters, coordinating cross-layer communication, and handling common maintenance tasks.

Metagraphs support decentralized opperation by recruiting community node operators. This improves throughput, resilience, and trust by distributing control of the network layers. Token-based incentives or staking models can be used to encourage participation.

As application logic changes over time, developers can deploy new versions of their metagraph software to update token rules, data validation, or fee behavior. These upgrades are handled directly by the metagraph team and don’t require global network coordination.

Overall, metagraphs offer flexible deployment options—from fully internal systems to open, community-driven networks—while maintaining interoperability through the Hypergraph.

Constellation’s protocol and metagraph development framework are built in Scala, a strongly typed, functional-first programming language that provides the precision and modularity needed to build scalable, secure, and reliable decentralized infrastructure.

Scala is used across both the Tessellation project (which implements the core protocol logic and Layer 0 consensus) and the (the developer framework for building metagraphs). This consistent foundation allows developers to reason about code with clarity while leveraging the full power of the underlying platform.

Why Scala?

Scala offers a unique combination of features that make it particularly well-suited for building a cryptocurrency network:

• Strong static typing helps eliminate entire classes of runtime errors and encourages safer, more predictable code.

• Functional programming constructs—such as immutability, monads, and pure functions—enable developers to write code that is modular, testable, and easier to reason about in concurrent or distributed environments.

• Object-oriented capabilities make it flexible and approachable for teams coming from traditional enterprise backgrounds.

• Concise, expressive syntax reduces boilerplate and encourages clean design without sacrificing power or control.

This blend of safety, expressiveness, and functional rigor aligns naturally with the design principles behind Constellation’s architecture: composability, parallelism, and data integrity at scale.

Scala runs on the Java Virtual Machine (JVM) and is fully interoperable with Java and other JVM-based languages. This allows Constellation developers to tap into a mature ecosystem of libraries and tools while writing modern, high-level code. Existing Java libraries can be seamlessly integrated, offering flexibility without compromising on language expressiveness or architectural clarity.

Constellation Network is designed to support high-throughput, low-cost applications without sacrificing decentralization or security. At the heart of this design is a flexible, modular fee system that allows most users to interact with the network for free while still supporting essential network operations, encouraging responsible usage, and enabling a scalable token economy.

Constellation’s approach to fees is guided by two core principles:

• Feeless by default, to reduce friction and support accessibility

• Fees where needed, to support network sustainability, security, and performance

Constellation Network uses a multi-layer consensus model to securely validate transactions and data across a scalable, modular network. This approach separates local consensus—where transactions are validated at the application or token level—from global consensus, which finalizes those updates and anchors them to the network's canonical state.

Consensus happens in two major phases:

1. Layer 1 (L1) Consensus – Validates transactions at the edge (e.g., DAG transfers, metagraph activity)

2. Layer 0 (L0) Consensus – Finalizes and records state across the entire network (via metagraph L0 or the Hypergraph)

This layered design enables horizontal scalability, data composability, and robust finality, while still maintaining a unified and trusted ledger.

L1 consensus is the first stage of validation for transactions and data submitted to the network. It takes place independently across three environments:

• DAG L1 – Validates transactions involving the native DAG token.

• Metagraph Currency L1 – Validates L0 token transactions received by individual metagraphs.

• Metagraph Data L1 – Validates application-specific data update transactions.

Each L1 environment is composed of a cluster of validator nodes. These nodes reach consensus on the validity of transactions using a DAG-based graph structure, where each node confirms and references others’ blocks. Consensus at this layer ensures that:

• Transactions are properly formed

• Signatures are valid

• Basic checks (e.g. balance, parent references) pass

Once a sufficient number of nodes agree on a set of validated data, that data is aggregated into a block or snapshot candidate and passed on to the next phase of consensus.

Consensus on L1 layers is parallelized and horizontally scalable, with rounds of consensus taking place across small groups of nodes (e.g., 3 nodes), providing rapid processing and validation of incoming transactions.

L0 consensus is where final agreement and ledger inclusion happen. It exists at two levels:

• Metagraph L0 – Each metagraph has its own Layer 0 that collects validated L1 transactions into a metagraph snapshot, performs final local checks, and submits it to the global network.

• Global L0 (Hypergraph) – This is the shared consensus layer that assembles snapshots from all metagraphs and the DAG L1 into a single global snapshot, which becomes part of the immutable ledger.

Each snapshot submitted to L0 is verified and either accepted or rejected. This final round of validation includes:

• Integrity of the snapshot structure and signatures

• Conformance with snapshot fee requirements

• Final checks on balances and transaction consistency

• Prevention of double spends and other malicious actions

Once approved, snapshots are added to the global snapshot and anchored to the network history.

Consensus at the global Layer 0 (Hypergraph) is maintained by a set of validator nodes, each of which must stake DAG collateral to participate. This forms the basis of Constellation’s modified proof-of-stake model, where validators are incentivized to behave honestly and maintain network integrity.

Validators participate in consensus by:

• Reviewing proposed snapshots

• Validating their contents

• Signing them for inclusion in the global snapshot

To protect against dishonest behavior:

• Nodes that sign invalid or conflicting data can be slashed, forfeiting their stake

• Validators that fail to meet performance or security standards can be removed from the active set

This staking and slashing model ensures that global consensus remains trust-minimized, economically secure, and decentralized.

In addition to stake-based participation, Constellation uses a reputation system called the PRO Score (Proof of Reputable Observation). This system introduces a trust layer on top of the consensus process by tracking and evaluating node behavior over time.

PRO Scores influence how nodes perceive and prioritize the signatures of their peers, especially in situations like:

• Minor forks or network splits

• Competing snapshots or state updates

• Peer selection and gossip propagation

Nodes with higher PRO Scores are considered more reputable and are more likely to be trusted during snapshot formation and conflict resolution. In future releases, PRO Scores will also influence rewards, validator rotation, and staking incentives.

Consensus in Constellation is layered, with different validation responsibilities assigned to different parts of the network.

This layered approach allows for secure and scalable consensus while supporting a wide range of token models, data systems, and applications.

Metagraphs support the ingestion, validation, and on-chain storage of application-specific data types. This data is submitted to the metagraph as DataUpdates, which are defined by the metagraph itself. These updates can represent any structured or semi-structured real-world data—from IoT sensor readings and business events to legal records, logs, analytics, or anything else meaningful to the domain the metagraph serves.

Each DataUpdate is a locally-defined transaction submitted to the metagraph’s Data L1 layer. This layer is responsible for parsing and validating the incoming data, enforcing application-specific logic, and participating in graph-based consensus rounds that produce blocks. Once a Data L1 block is finalized, it is sent to the Metagraph L0, where a second layer of validation and finalization takes place. The L0 layer aggregates blocks into a metagraph snapshot, which is the authoritative unit of state for the metagraph and is submitted to the Global L0 (Hypergraph) for final consensus and inclusion in a global snapshot.

Defining Custom Data Behavior

Metagraph developers define their custom data schema and logic by extending DataApplication in the Metagraph Framework. This allows developers to specify:

• How incoming data should be decoded

• What signature or authentication rules should apply

• Any domain-specific validation logic that determines whether a DataUpdate is accepted or rejected

• How updates should be grouped into blocks

• What data should be added to local, working memory (Calculated State)

• Whether and how data is stored on-chain (e.g., full payloads vs. notarized hashes)

These capabilities make metagraphs highly adaptable to a wide range of use cases. For example:

• A metagraph used in public safety might ingest vehicle telemetry and timestamped incident logs, notarizing them for legal verification.

• A supply chain metagraph might process signed delivery confirmations and proof-of-origin certificates.

• A healthcare metagraph might process encrypted patient records, with selective notarization for audit and compliance.

Because DataUpdates are handled within the metagraph’s own L1 and L0 layers, each metagraph can independently enforce its own trust assumptions, data models, and regulatory constraints—while still anchoring finalized state to the Hypergraph for global ordering and provability.

Developers also have control over how data is stored and queried. Not all data needs to be stored in full on-chain. Many metagraphs choose to store only hashes or references on-chain to preserve privacy or reduce storage costs, while maintaining cryptographic guarantees about the data’s authenticity and timestamp.

Custom data processing on metagraphs can also be linked with FeeTransactions, which enable pay-per-update business models. A FeeTransaction contains a cryptographic reference to the data it is associated with, allowing a metagraph to tie utility (data validation and storage) to token-based compensation in a verifiable way.

Metagraphs offer a powerful and flexible environment for building domain-specific data pipelines with on-chain guarantees. The combination of custom logic, horizontal scalability, and Hypergraph anchoring enables developers to build high-integrity, application-specific blockchain systems that are purpose-built for real-world workflows and data integrity requirements.

The following global transaction types are supported across the network.

Transaction Types

DAG Transaction

A standard currency transaction that transfers DAG tokens between two addresses.

A standard transaction for transferring L0 tokens within a metagraph’s currency layer.

Same as DAG Transaction, but amount and fee are denominated in L0 tokens.

A delegation transaction that pre-approves spending on behalf of the sender.

A metagraph-generated transaction that either:

1. Uses an AllowSpend to execute a transfer, or

2. Moves funds from a metagraph-owned wallet.

If an AllowSpend is referenced, the SpendTransaction can spend up to the amount of the AllowSpend, or less. Once an AllowSpend is referenced in an accepted SpendTransaction, the AllowSpend lock is released and the transaction cannot be used again for a future SpendTransaction.

A transaction associated with submitting data to a metagraph’s Data L1.

Locks funds for a specified duration or indefinitely. Locked funds are deducted from a wallet's balance for the duration of the lock but are never transferred from the wallet.

A system-generated transaction that unlocks previously locked tokens. TokenUnlock transactions can be created by metagraphs (L0 tokens) and the global L0 (DAG) to unlock a TokenLock before its unlockEpoch, or to unlock a TokenLock with no unlockEpoch. This transaction type is also emitted when a TokenLock has reached its unlockEpoch.

A system-generated transaction that marks an expired AllowSpend.

A user-generated transaction to create or update a delegated stake position. A delegated staking position is comprised of two parts:

• A TokenLock with an indefinite expiration

• An UpdateDelegatedStake transaction referencing the TokenLock

This transaction can be used to update an existing delegated stake position without requiring a withdrawal first. The updated delegated stake transaction will have all the same details as the original, except with a different nodeId referenced.

A user-generated transaction to unwind a delegated staking position. After the WithdrawDelegatedStake transaction is accepted, the associated TokenLock will be unlocked by the network after 21 days (measured by epochProgress).

A user-generated transaction to create a node collateral position. A node collateral position is comprised of two parts:

• A TokenLock with an indefinite expiration

• An UpdateNodeCollateral transaction referencing the TokenLock

This transaction can be used to update an existing delegated stake position without requiring a withdrawal first. The updated delegated stake transaction will have all the same details as the original, except with a different nodeId referenced.

A user-generated transaction to unwind a node collateral position. After the WithdrawNodeCollateral transaction is accepted, the associated TokenLock will be unlocked by the network after 21 days (measured by epochProgress).