Advanced Token Functionality

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.

Token Locking

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

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.

Custom Transfer Fees

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.

Last updated

Was this helpful?