Overview

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.

The Role of Snapshots on the Network

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 Snapshot Lifecycle

The process of snapshot creation follows a structured lifecycle, starting with L1 block formation, progressing through L0 validation and aggregation, and concluding with finalization and inclusion in the snapshot chain.

At the L1 level, multiple independent layers operate in parallel, each producing blocks that contain transactions relevant to their domain. For example, DAG L1 processes standard network transactions, while Currency L1 handles token-based operations. Validators in each L1 execute transactions, package them into blocks, and submit them to the L0 layer.

Once L1 blocks reach the L0 layer, they undergo validation to ensure correctness and consensus agreement. The Hypergraph’s L0 nodes verify the integrity of these blocks, confirm their inclusion criteria, and aggregate them into a snapshot. Each snapshot contains a finalized record of all validated L1 blocks within that period, along with a Merkle root summarizing the network state.

After validation, the snapshot is proposed to the network for consensus. Once finalized, it is added to the snapshot chain, permanently recording all included transactions and metagraph state updates. This process repeats continuously, allowing the network to progress efficiently without relying on a rigid sequential block structure.

Snapshot Triggers

Snapshot creation can be triggered in two ways: on-demand or at timed intervals.

On-demand snapshots are triggered whenever new L1 blocks are received by the L0 layer. As soon as enough data is available, the network initiates a round of consensus, ensuring that transactions are processed as quickly as possible. This mechanism allows for rapid state updates and fast transaction finality times.

Timed snapshots, on the other hand, are produced at regular intervals of approximately one minute, regardless of whether new blocks have been submitted. These timed snapshots serve an additional purpose beyond finalizing transactions—they increment the epochProgress value, providing a rough measure of time within the network. This concept of network time is crucial for operations that depend on periodic updates, such as validator reward distribution. Unlike on-demand snapshots, which are created as needed, timed snapshots ensure that certain protocol mechanisms execute at predictable intervals.

Metagraph Snapshot Lifecycle

Each metagraph follows a similar process to the Hypergraph for state progression. Metagraphs operate their own L1 layers, where transactions specific to that metagraph are processed and finalized into blocks. These blocks are validated by the metagraph’s L0 layer and aggregated into metagraph snapshots.

To ensure security and finality, metagraph snapshots are periodically submitted to the Hypergraph. Once included in a Global Snapshot, they become part of the immutable network history, securing metagraph state alongside Hypergraph state. This hierarchical model allows metagraphs to maintain autonomy while still benefiting from the Hypergraph’s global validation and consensus.

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.

Layer 1 (L1) Consensus

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.

Layer 0 (L0) Consensus

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.

Validator Participation and Security

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.

PRO Score: Layered Trust and Reputation

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.

Summary

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.

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.

Key Features

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.

• Delegated spending (AllowSpend and SpendTransaction): A two-step authorization model that allows metagraphs or users to act on behalf of another wallet under controlled, pre-approved conditions.

• Token locking (TokenLock): Mechanisms to temporarily restrict the movement of tokens for staking, governance, or collateral purposes—without transferring custody.

• Data-associated transactions (FeeTransaction): Transactions that are cryptographically tied to on-chain data updates, supporting pay-per-use models, e-commerce, and auditability.

These capabilities allow tokens to act not just as units of value, but as programmable instruments in dynamic applications, DAOs, and cross-metagraph systems.

DAG and L0 Token Equivalence

While DAG is the native token of the network and used to pay snapshot fees (the cost to include a transaction in the consensus snapshot), it adheres to the same standard as metagraph-issued L0 tokens. This creates parity between DAG and custom tokens from a functional standpoint, ensuring that tools like wallets and explorers can treat them uniformly while maintaining DAG’s special utility role at the protocol level.

Automatic Adoption via Euclid SDK

Any metagraph that implements the Euclid SDK’s currency layer automatically inherits the full capabilities of the L0 Token Standard. This ensures that developers building on Constellation don’t have to reimplement token logic or manage interoperability on their own—these features are built into the framework.

The L0 Token Standard is the connective tissue of Constellation Network’s currency layer, enabling composability, utility, and programmability across an evolving ecosystem of interoperable metagraphs.

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.

Core Concepts

• 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.

Layer Definitions

Metagraph L0

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.

Currency L1

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

• Submits finalized blocks to the metagraph L0 layer

Data L1

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

• Submits finalized blocks to the metagraph L0 layer

Global L0 (Hypergraph)

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.

Scaling Considerations

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.

Summary

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.

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.

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

This section provides an overview of how network fees function across different layers of the network, including peer-to-peer DAG transactions and metagraph activity.

Why Fees Exist

Unlike traditional blockchains that apply flat fees to every transaction, Constellation applies fees only when necessary. Fees serve several critical functions:

• Security: They deter abuse by making spam attacks, resource hoarding, or denial-of-service attempts economically unfeasible.

• Prioritization: Fees can be optionally included to increase the priority of certain actions, ensuring timely processing in high-demand scenarios.

• Resource Allocation: Fees are used to manage storage, computation, and bandwidth in a way that incentivizes efficient use of network resources.

• Economic Incentives: Validators and infrastructure providers are rewarded through the redistribution of fees, creating a sustainable incentive model.

• Network Subsidy: Low or zero fees act as an intentional subsidy to stimulate adoption and experimentation, particularly in the early phases of network growth.

This model creates a flexible fee economy where light users can interact freely, and heavy users or high-performance applications help fund the system.

L0 Token Transaction Fees

DAG and metagraph-hosted L0 tokens support peer-to-peer transactions between wallets on the DAG or Metagraph Currency L1 layer. These transactions are feeless by default, meaning users can send and receive tokens without paying a fee in most cases.

However, optional fees can be included in a transaction to:

• Prioritize it for inclusion in the next snapshot

• Trigger parallel consensus

• Bypass rate limits that apply to high-volume or low-balance accounts

This tiered system enables different levels of service based on user needs and prevents network abuse without excluding legitimate use.

Example Use Case

If a wallet needs to send hundreds of transactions quickly (e.g., for an airdrop), it can attach a small fee (e.g., 1 datum or more) to each transaction. This ensures priority processing and higher throughput, while ordinary users sending occasional transactions continue to operate for free.

Low Balance Rate Limits

To mitigate spam from wallets with negligible balances, a dynamic rate limit is applied to accounts with low DAG holdings. This limit can be bypassed by attaching a small fee (0.002 DAG) to a transaction.

This strategy ensures that wallet spam becomes prohibitively expensive, protecting network performance without disrupting typical usage patterns.

Custom Metagraph Transaction Fees

Each metagraph has the flexibility to define its own internal fee logic for transactions and services within its domain. This allows metagraphs to implement business models, incentives, and cost structures tailored to their specific use case—all while staying interoperable with the rest of the network.

Data Update Fees

Metagraphs can associate L0 token payments directly with data submissions using the FeeTransaction type. This creates a native mechanism for pay-per-use functionality, where users pay for access to specific services, datasets, or on-chain actions.

Key characteristics:

• FeeTransaction is cryptographically linked to a data submission but does not include the data itself—preserving user privacy.

• It allows metagraphs to monetize access to data, trigger logic only when payment is received, or implement rate-limiting based on fee volume.

• Transactions can be submitted atomically alongside their associated data updates, ensuring consistency between payment and action.

Custom L0 Token Fees

Metagraphs using the Euclid SDK Currency Layer can enforce minimum fee requirements on L0 token transfers. These rules can be based on custom business logic, such as:

• Fixed minimum transfer fees per transaction

• Tiered fees based on token amount or user role

• Dynamic fees based on network activity or metagraph load

• Governance-controlled fee schedules

Because metagraphs control their own business logic, they can determine when and how to charge users for token transfers, staking, or in-app utility—without requiring changes to the global protocol.

Snapshot Fees

While peer-to-peer usage is largely feeless, metagraphs interact with the network in more complex ways. These interactions are subject to required snapshot fees, which are currently the only mandatory fees on the network.

Who Pays

Snapshot fees are paid by metagraph operators, not end users. This allows each metagraph to determine how or whether to pass costs along to its users. Projects can cover fees themselves, subsidize usage through staking rewards or grants, or introduce custom fee models at the application level.

What Fees Pay For

Snapshot fees support:

• Global consensus validation of metagraph data

• Secure data storage by archive nodes

• Proof-of-record for any data or token activity committed to the Hypergraph

These fees are denominated in DAG and deducted from a designated metagraph fee wallet.

How Snapshot Fees Are Calculated

Snapshot fees are determined by the following formula:

Fee = (baseFee × WorkAmount × workMultiplier) + optionalTip

Key Inputs:

• WorkAmount: Reflects both the size (in KB) and computational complexity of the submitted data.

• WorkMultiplier: A reduction factor based on the amount of staked DAG and the metagraph’s PRO Score.

• Optional Tip: An extra fee a metagraph can include to prioritize its snapshot during network congestion.

Snapshot fees are fixed, not market-driven, which ensures predictability and easier budgeting for metagraph projects.

Fee Wallets and Staking

Each metagraph must designate a fee wallet to pay for snapshots and a staking wallet to qualify for reduced fees. Only DAG in the staking wallet counts toward fee reductions—collateral or DAG stored in other wallets does not.

Staking DAG:

• Reduces snapshot fees through the workMultiplier

• Signals long-term commitment to the network

• Contributes to network security by removing tokens from circulation

Fees can never be reduced to zero, but large staked balances significantly lower operational costs for active metagraphs.

Summary

Constellation Network’s fee model is designed for scale, flexibility, and fairness. Most everyday usage is free or extremely low-cost, while higher-intensity or system-critical operations are funded through proportional fees.

This structure:

• Encourages innovation and accessibility

• Protects the network from misuse

• Supports validator incentives and long-term sustainability

• Enables developers to launch metagraphs with flexible economic models

As the network evolves, fees will remain an essential tool—not just for paying for resources, but for shaping user behavior, securing infrastructure, and growing a healthy, decentralized economy.

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.

Transaction Fields

Example

L0 Token Transaction

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

Transaction Fields

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

AllowSpend

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

Transaction Fields

Example

SpendTransaction

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.

Transaction Fields

Example

FeeTransaction

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

Transaction Fields

Example

TokenLock

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.

Transaction Fields

Example

TokenUnlock

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.

Transaction Fields

Example

AllowSpendExpiration

A system-generated transaction that marks an expired AllowSpend.

Transaction Fields

Example

UpdateDelegatedStake

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.

Transaction Fields

Example

WithdrawDelegatedStake

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).

Transaction Fields

Example

UpdateNodeCollateral

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.

Transaction Fields

Example

WithdrawNodeCollateral

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).

Transaction Fields

Example

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.

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.

Ecosystem Interoperability

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.

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.

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.

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.

Example Calculation

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

Thus, the Check Digit is 5.

Deriving an Address from a Public Key

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.