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?