Chialisp Guide Pt 11: Royalty Tokens & NFT1/NFT2

Key Takeaways

• Chialisp royalty tokens ensure creators earn perpetual revenue through immutable puzzle logic enforced at the smart coin level, not by centralized marketplaces
• The NFT1 standard launched in June 2022 embeds royalty percentages and creator puzzle hashes directly into NFT puzzles, making them tamper-proof and permanent
• CHIP-0008 splitter puzzles allow automatic royalty distribution to multiple addresses, enabling collaborative creator payments without trust requirements
• Chia Offers primitive enforces royalty payments atomically during trades, preventing marketplace circumvention that plagues other blockchains
• Building royalty mechanisms requires understanding currying techniques, coin spend conditions, and proper integration with CATs and NFT layers

Article Summary

Chialisp royalty tokens are smart coins programmed with perpetual creator payment rules that execute automatically during every trade, enforced through puzzle logic rather than marketplace policies. Unlike centralized platforms where royalties can be bypassed or disabled, Chia’s NFT1 standard curries royalty data directly into the puzzle during minting, creating immutable payment streams that benefit creators, collaborators, and entire ecosystems through mechanisms like CHIP-0008 splitter puzzles.

Understanding Chialisp Royalty Tokens

When you build applications on traditional blockchains, creator royalties depend on marketplace cooperation. A platform can simply turn off royalty enforcement with a policy change, leaving artists without their expected income. Chialisp royalty tokens solve this fundamental problem by programming payment rules directly into the puzzle logic itself.

Think of it like the difference between a handshake agreement and a legal contract baked into the ownership certificate. In Chialisp, every token is a smart coin governed by a puzzle. When you spend that coin, the puzzle’s conditions must be satisfied. For royalty tokens, one of those conditions is sending a specific percentage to the creator’s address. No marketplace can override this because the blockchain itself enforces the rules.

The beauty of this approach becomes clear when you realize that royalties become as fundamental to the token as its ability to be transferred. Just like you can’t spend someone else’s coin without their private key, you can’t trade a royalty-enabled NFT without paying the creator their share. This protection extends far beyond digital art into gaming assets, music rights, real estate tokens, and any digital good where creators deserve ongoing compensation.

How Perpetual Royalties Work in Chialisp

Every Chia NFT is actually a coin with a specific puzzle controlling its behavior. When an NFT mints with royalty support, the creator defines two critical pieces of data. First, the royalty percentage, typically expressed in basis points where 300 equals three percent. Second, the creator puzzle hash where royalty payments get sent. These values get curried into the NFT’s puzzle during minting, meaning they become permanent parts of the puzzle’s code.

When someone creates an offer to trade the NFT for XCH or CATs, the offer file includes the NFT’s current puzzle. Because the royalty percentage and destination address are curried in, anyone accepting the offer must satisfy those conditions. The Chia Offers primitive verifies that the correct royalty amount gets paid to the creator address before the trade completes atomically. This happens entirely on-chain without any marketplace involvement.

Consider a practical scenario. You mint an NFT with a five percent royalty pointing to your puzzle hash. Someone buys it from you for 10 XCH. Later, they sell it for 100 XCH. Your puzzle hash automatically receives 5 XCH during that second sale. The new owner later sells for 200 XCH, and you receive 10 XCH. This continues perpetually for the NFT’s entire lifespan, creating a revenue stream that grows with the asset’s success.

NFT1 Standard and Current Implementation

Chia launched the NFT1 standard in June 2022 after extensive testing with NFT0 on testnet. NFT1 introduced native royalty support, DID integration for provenance tracking, and the Offers primitive for peer-to-peer trading. The standard specifically addressed problems plaguing other blockchain NFT ecosystems, including marketplace lock-in, royalty circumvention, and unclear ownership history.

The NFT1 standard remains Chia’s current and only official NFT standard as of 2026. Most developers working with Chia NFTs today use the NFT1 standard, which provides robust support for royalties, multiple URI storage for permanence, and DID-based identity verification. Understanding NFT1 thoroughly gives you the foundation needed for building sophisticated royalty-enabled NFT applications on Chia.

Building Your First Royalty-Enabled NFT

From our previous lessons on Chialisp fundamentals, currying, and puzzle composition, you now have the skills to implement royalty tokens. The core concept involves currying royalty data into your NFT puzzle before minting. Let’s walk through this process step by step, building on techniques you learned in Lessons 01 through 10.

Setting Up the Royalty Puzzle

Before writing any Chialisp code, you need to understand what data gets curried into your NFT puzzle. Every royalty-enabled NFT requires these curried parameters: the royalty percentage in basis points, the creator puzzle hash to receive payments, and optionally a splitter puzzle hash if multiple recipients share royalties. These parameters become part of the puzzle’s permanent structure.

Start by defining your royalty percentage. Common values range from 250 basis points (2.5%) to 1000 basis points (10%), with 300 to 500 (3% to 5%) being typical for digital art. Higher percentages may discourage trading, while lower percentages might not provide meaningful creator compensation. You’ll curry this value during minting and it cannot change afterward.

Next, determine your creator puzzle hash. This is the address where royalty payments land. You can use a standard wallet address puzzle hash, or for more sophisticated setups, a splitter puzzle hash that distributes payments to multiple recipients. We’ll cover splitter puzzles in detail shortly.

Minting with CLI Royalty Parameters

The Chia wallet CLI provides commands to mint NFTs with royalty support enabled. You’ll need a synced full node, a wallet with some XCH for minting fees, and optionally a DID for creator identity. The minting command accepts royalty parameters that get curried into your NFT puzzle automatically.

Here’s the basic minting syntax including royalty parameters. Open your terminal and ensure your Chia wallet is running and synced. The command structure is: chia wallet nft mint -i [wallet_id] -ra [royalty_address] -rp [royalty_percentage] -u [URI] -nh [content_hash]. The wallet ID identifies which NFT wallet receives the minted token. The royalty address is where payments go. The royalty percentage is in basis points.

For a concrete example, if you want to mint an NFT with 5% royalties paid to address xch1abc...xyz, you’d use: chia wallet nft mint -i 2 -ra xch1abc...xyz -rp 500 -u //example.com/art.png -nh 0x1234...5678. This creates an NFT in wallet 2, sets a 500 basis point (5%) royalty to the specified address, links to your artwork URI, and includes the content hash for verification. The royalty data is now permanently curried into the NFT puzzle.

Verifying Royalty Implementation

After minting, you should verify that royalties were properly curried into your NFT puzzle. Use the chia wallet nft get_info command with your NFT’s identifier. This displays all curried parameters including the royalty percentage and creator puzzle hash. Look for the royalty percentage field showing your chosen basis points and the royalty puzhash showing where payments go.

The output will show something like: “Royalty percentage: 500” and “Royalty puzhash: 0x827d…17a8”. The percentage confirms your five percent royalty, and the puzzle hash is the derived form of your creator address. This data cannot be changed without destroying the NFT and minting a new one, providing creators with certainty that their royalty stream is protected.

Quick Decision Guide: Choosing Your Royalty Implementation

CHIP-0008: Splitter Puzzles for Multi-Party Royalties

Many creative works involve multiple contributors who deserve royalty shares. Traditional systems require trust or complex legal agreements to split payments fairly. CHIP-0008 introduces a standard Chialisp puzzle that automatically divides incoming payments according to predefined percentages. This creates trustless royalty distribution without any intermediary party.

The splitter puzzle works by accepting a list of output puzzle hashes and their corresponding shares. When the splitter coin receives a payment (like an NFT royalty), spending it requires creating outputs that match the specified distribution. For example, a three-person collaboration with 40%, 30%, and 30% shares would require the spend to create three coins with exactly those proportions of the input amount.

Implementing a Splitter Puzzle

Setting up a splitter starts with defining your payout scheme. List each recipient’s puzzle hash and their share count. The puzzle divides the total amount by the sum of all shares, then allocates to each recipient accordingly. This approach avoids rounding errors that plague percentage-based systems.

For instance, imagine three artists collaborate on an NFT collection with different contribution levels. Artist A contributed 50% of the work, Artist B contributed 30%, and Artist C contributed 20%. You would curry their puzzle hashes and shares (5, 3, 2) into the splitter puzzle. The total shares equals 10. When a 10 XCH royalty arrives, Artist A receives 5 XCH, Artist B receives 3 XCH, and Artist C receives 2 XCH.

The splitter puzzle itself handles XCH by default. For CAT support, you need additional logic to track the CAT’s asset ID and ensure proper accounting. Some implementations require pre-defining which CATs the splitter accepts to prevent unspendable coins from CAT rounding issues. This adds complexity but enables fungible token royalty splits.

Splitter Security Considerations

Splitter puzzles must enforce that the sum of outputs equals the input amount. Missing this validation allows attackers to drain the splitter by creating insufficient outputs. The CHIP-0008 specification includes proper validation checks. Always verify outputs sum correctly and that the number of outputs matches the number of recipients before accepting a spend.

Another consideration involves excess mojos from rounding. When dividing an odd number of mojos by certain share counts, you get remainders. The standard CHIP-0008 implementation allocates excess mojos to the last recipient or to a farmer fee, preventing them from making the coin unspendable. Your implementation should clearly define this behavior.

Memos and hints help wallets recognize incoming splitter payments. Without proper hints, your wallet might not detect the coin as spendable. Include memos that identify the splitter type and parameters so wallet software can reconstruct the puzzle and find your coins. This user experience consideration prevents accidentally “losing” funds that are technically on-chain but invisible to your wallet.

Integrating Royalties with CATs and Offers

Chia Asset Tokens (CATs) represent fungible tokens on Chia, governed by TAIL programs that define issuance rules. Combining CAT functionality with royalty mechanisms creates powerful economic models. A game developer might issue a CAT representing in-game currency where every transfer includes a small royalty to the development fund. This provides ongoing revenue as the economy grows.

TAIL Programs and Royalty Logic

The TAIL (Token and Asset Issuance Limitations) program runs whenever a CAT spends, verifying that supply never changes unless issuance rules allow. You can embed royalty-like behavior in the TAIL by requiring certain outputs during specific spend types. For example, a TAIL might enforce that melting tokens back to XCH requires sending a percentage to a treasury address.

Implementing this requires understanding CAT spend accounting. All CATs in a spend bundle must sum to the same total before and after. If you melt 100 tokens into 100 XCH worth of value, but the TAIL demands 5% goes to treasury, you need to ensure the CAT accounting and royalty outputs both satisfy their respective conditions. This often means coordinating multiple coins in a single spend bundle.

Offer Files and Royalty Enforcement

Chia Offers enable trustless peer-to-peer trading. When someone creates an offer to buy an NFT with XCH or CATs, the offer file specifies exactly which coins they’ll receive and which coins they’ll give up. For royalty-enabled NFTs, the offer must include coins that satisfy the royalty payment condition. Otherwise, the offer cannot be accepted.

This creates natural royalty enforcement. Marketplace developers don’t need to voluntarily support royalties because the blockchain itself rejects trades that don’t pay them. A buyer creating an offer for your NFT must include enough XCH or CAT coins to cover both the seller’s payment and the creator’s royalty. The offer file explicitly shows this split, making royalty payments transparent and verifiable before acceptance.

Consider building a marketplace interface. Your code should parse the NFT’s puzzle to extract the royalty percentage and creator puzzle hash. When a buyer wants to purchase for 100 XCH at 5% royalty, your interface creates an offer with 95 XCH to the seller and 5 XCH to the creator. Both parties can inspect the offer file before accepting, ensuring the terms are correct. This transparency builds trust without requiring marketplace mediation.

Advanced Royalty Patterns and Use Cases

Basic royalty implementations cover most art and collectible scenarios. Advanced patterns unlock functionality for gaming, real estate, music rights, and complex financial instruments. Understanding these patterns expands what you can build with Chialisp royalty tokens.

Tiered Royalty Systems

Some creators want different royalty rates at different price points. A high-value NFT selling for 1000 XCH might support a 10% royalty, while the same NFT at 10 XCH could have 3% to encourage trading. Implementing this requires conditional logic in your puzzle that checks the sale amount and applies the appropriate rate.

You can curry a list of price thresholds and corresponding rates into your puzzle. The puzzle evaluates the sale amount against these thresholds and selects the matching rate. This adds complexity but enables sophisticated economic models. For example, an NFT representing a music album might charge 10% for sales under 100 XCH, 7% for 100-500 XCH, and 5% for sales above 500 XCH, encouraging appreciation while protecting the creator.

Royalty Pools and DAOs

Instead of paying royalties to a single address, you might route them to a DAO treasury or liquidity pool. This requires the creator puzzle hash to point to a more complex puzzle that implements DAO governance or automated market maker logic. Contributors can then vote on how to use accumulated royalties or claim proportional shares based on their DAO tokens.

For example, imagine an NFT collection where royalties fund ongoing development. The creator puzzle hash points to a DAO smart coin. Every trade sends royalties there. Token holders vote on proposals like commissioning new artwork, funding promotional campaigns, or distributing dividends. This aligns creator incentives with collector success and builds thriving communities around digital assets.

Declining Royalty Curves

Some tokenomics models benefit from royalties that decrease over time or with each trade. This rewards early supporters more heavily while reducing friction for later trades as the asset matures. Implementing this requires the puzzle to track trade count or time elapsed since minting, adjusting the royalty percentage accordingly.

One approach curries a starting royalty percentage and a decay function into the puzzle. Each spend increments a counter that modifies the applied rate. After 10 trades, the initial 10% royalty might drop to 5%. After 100 trades, it might bottom out at 1%. This encourages long-term holding initially while enabling more liquid trading as the asset’s market matures.

Expert Insight on Chialisp Royalties

“With our goal to drive adoption, we know that the ability to link your identity, on-chain royalties, and Chia Offers are new and significant functional components to the future of NFTs.”

— Richard Tsao, Vice President of NFT Business Development at Chia Network

Real-World Implementation: Chia Friends NFT Collection

When Chia Network launched the NFT1 standard in June 2022, they demonstrated royalty functionality through the Chia Friends collection. This limited edition set of 10,000 procedurally generated profile picture NFTs included a five percent royalty on all secondary sales. Uniquely, all royalty proceeds went to The Marmot Recovery Foundation, showcasing how royalties can fund charitable causes perpetually.

The Chia Friends implementation highlighted several important features. First, every NFT in the collection used identical royalty parameters curried into the puzzle during minting, ensuring consistency across all 10,000 tokens. Second, the royalty destination was a foundation address rather than an individual creator, proving the flexibility of the system. Third, trades occurred entirely peer-to-peer using Offer files, with no centralized marketplace required to enforce royalty payments.

This case study proved that on-chain royalty enforcement works at scale. As Chia Friends NFTs traded on various platforms including Dexie and MintGarden, every transaction automatically included the five percent payment to the Marmot Recovery Foundation. The blockchain guaranteed this without requiring marketplace cooperation, policy enforcement, or trust. For creators, this represented a fundamental shift from other ecosystems where marketplace policy changes could eliminate royalty income overnight.

Comparing Royalty Implementations Across Ecosystems

Common Pitfalls and How to Avoid Them

Implementing royalty tokens introduces several common errors. Understanding these pitfalls helps you build robust systems that protect creator revenue and maintain user experience. Let’s examine the most frequent mistakes and their solutions.

Incorrect Basis Point Calculations

Royalty percentages use basis points where 100 equals one percent. New developers sometimes confuse this with straight percentages, setting a five percent royalty as 5 instead of 500. This results in a 0.05% royalty, giving creators almost nothing. Always verify your basis point conversion. Five percent equals 500 basis points, ten percent equals 1000 basis points, and so on.

Test your royalty implementation with small transactions first. Mint a test NFT with your chosen royalty rate, then create an offer to trade it for a known amount of XCH. Verify that the royalty output matches your expectations. If you set 500 basis points and trade for 100 XCH, you should see exactly 5 XCH going to the creator address. Catching this error before mainnet deployment saves significant embarrassment and potential creator compensation disputes.

Wrong Puzzle Hash Format

Puzzle hashes must be in the correct format for the puzzle to recognize them as valid destinations. Using a bech32 address directly instead of converting it to the puzzle hash format causes the mint to fail or creates unspendable royalty outputs. Always convert addresses to puzzle hashes using the proper CLI tools or Python libraries before currying them into puzzles.

The conversion is straightforward with Chia tools. Use cdv decode to convert a bech32 address to its puzzle hash, or use the chia wallet get_address command with the -n flag to display the puzzle hash alongside the address. Store this puzzle hash and use it in your royalty currying. This ensures royalty payments land at addresses where recipients can actually access them.

Forgetting CAT Compatibility

If your NFT might trade for CATs in addition to XCH, your royalty logic must account for this. A simple XCH-only royalty implementation breaks when someone creates an offer involving multiple asset types. You need to either restrict trades to XCH only or implement proper CAT handling in your royalty puzzle.

The Chia protocol documentation provides patterns for multi-asset royalty calculation. Essentially, you need to pro-rate the royalty across all assets in the trade proportional to their values. A 100 XCH + 500 USDS trade at 5% royalty should send 5 XCH + 25 USDS to the creator. This requires additional puzzle logic but ensures your NFTs work seamlessly across the entire Chia ecosystem.

Building Custom Royalty Mechanisms

While NFT1 standard royalties and CHIP-0008 splitters cover most use cases, sometimes you need custom logic. Building your own royalty puzzle gives you complete control over payment conditions, enabling innovative economic models. Let’s explore how to construct a custom royalty mechanism from Chialisp primitives.

Designing Your Royalty Puzzle

Start by defining what conditions must be satisfied for a valid spend. At minimum, you need to verify that the royalty amount is correctly calculated and sent to the creator address. More complex implementations might check trade amounts, time constraints, or integration with external oracles. Write these requirements as clear specifications before touching code.

Consider a puzzle that implements exponential royalty decay. You want 10% royalties for the first 30 days after minting, 5% for the next 30 days, and 2% thereafter. Your puzzle needs to curry in the mint timestamp, check the current time during spend, calculate the elapsed period, select the appropriate rate, and enforce the corresponding payment. This involves combining multiple Chialisp techniques from previous lessons.

Implementing Royalty Conditions

The core of your custom puzzle should calculate the required royalty amount and create a CREATE_COIN condition for it. This looks something like: calculate the sale amount by examining the spend bundle, multiply by the royalty rate, divide by 10,000 to convert basis points, then create a coin for that amount at the creator puzzle hash.

Here’s a simplified Chialisp pattern. Your puzzle receives the sale amount in the solution. It curries in the royalty rate and creator puzzle hash. The puzzle then computes: (defun calculate-royalty (amount rate) (* amount rate) / 10000)). It creates a CREATE_COIN condition with this amount and the creator puzzle hash. Finally, it returns this condition along with any other required conditions for the spend to be valid.

Testing Custom Royalty Logic

Custom puzzles require thorough testing before mainnet deployment. Use the Chia simulator to test various scenarios: normal trades, edge cases like 1 mojo sales, maximum value trades, and attempts to bypass royalty payments. Verify that your puzzle correctly enforces payments in all cases and gracefully handles unexpected inputs.

Build a test suite that covers your royalty logic thoroughly. Test with different sale amounts, multiple buyers, CAT integration if relevant, and timestamp manipulation for time-based logic. Any bug in production royalty code could permanently affect creator revenue, so testing is not optional. Consider having your code audited if it will secure significant value or many creators depend on it.

Security Best Practices for Royalty Tokens

Royalty puzzles handle value flow, making them attractive targets for attackers. Following security best practices protects both creators and collectors. These guidelines come from lessons learned across the Chia ecosystem and broader blockchain security research.

Validate All Inputs

Never trust data from solutions. Validate every input your puzzle receives before using it in calculations. If your puzzle expects a sale amount, verify it matches the actual coins being created in the spend bundle. If it expects a timestamp, validate it against blockchain height or other reliable sources. Unchecked inputs allow attackers to manipulate royalty calculations or bypass payments entirely.

Use assertions liberally. If a value must be positive, assert it’s greater than zero. If it must fall within a range, assert the boundaries. If it must match a specific format, validate the format before using it. These checks add minimal cost but prevent entire classes of exploits. Think of input validation as the foundation of secure puzzle design.

Prevent Integer Overflow and Underflow

Royalty calculations involve multiplication and division. Large numbers can overflow standard integer types, wrapping around to small values. This could let an attacker trade a high-value NFT while paying minimal royalties. Use safe arithmetic operations that detect overflow, or structure your calculations to guarantee they stay within safe ranges.

Chia’s Chialisp uses arbitrary precision integers, which prevents many overflow issues. However, you still need to be careful when converting between different representations or when working with limited-precision values from external sources. Test your royalty calculations with maximum possible values to ensure they behave correctly at extremes.

Immutable Royalty Parameters

Royalty percentages and creator addresses should be immutable once set. Currying these values into the puzzle achieves this. Avoid designs where royalties can be modified post-minting unless you have a very specific use case requiring it. Immutability protects creators from malicious changes and gives collectors confidence in the terms they agreed to.

If you absolutely must support royalty updates, implement a secure governance mechanism. This might involve multisig requirements, time delays, or DAO voting. Never allow a single party to unilaterally change royalties on existing tokens. Such changes violate collector expectations and undermine trust in your platform.

Optimizing Gas Costs for Royalty Transactions

Every spend on Chia has a cost in fees and CLVM execution. Royalty puzzles add complexity, which can increase these costs. Optimizing your implementation reduces the burden on users while maintaining security and functionality. Several techniques help minimize costs without compromising features.

Minimize Puzzle Complexity

Simpler puzzles cost less to execute. Review your royalty logic and eliminate unnecessary calculations. Can you precompute values during currying instead of calculating them every spend? Can you simplify conditional branches? Can you reuse common utility functions from established libraries? Each reduction in puzzle complexity directly translates to lower costs.

Consider using lookup tables instead of complex calculations for common scenarios. If you have a tiered royalty system with just three tiers, curry the rates directly rather than implementing a complex calculation function. The upfront complexity is higher but runtime execution is much cheaper. Profile your puzzle to identify expensive operations and focus optimization efforts there.

Batch Royalty Distributions

For high-volume NFT collections, individual royalty payments on every trade can accumulate significant fees. Consider accumulating royalties in a holding coin and distributing them periodically. This batches many small payments into fewer large ones, reducing overall network costs. The tradeoff is that creators receive payments less frequently.

Implementing batched distributions requires a more complex puzzle that can accumulate value and then distribute according to a schedule or threshold. You might curry in a minimum payout amount, collecting royalties until that threshold is reached before sending to the creator. Or you might implement a time-based system that allows distribution once per week. Choose an approach that balances creator convenience with cost efficiency.

Conclusion

Chialisp royalty tokens represent a fundamental innovation in creator compensation. By encoding payment rules directly into puzzle logic and leveraging Chia’s coin set model, they achieve true marketplace independence. Creators no longer depend on platform policies to receive their fair share. Collectors gain confidence that the terms they agreed to cannot change arbitrarily. The entire ecosystem benefits from sustainable creator incentives that reward quality work perpetually.

From basic NFT1 royalties to sophisticated CHIP-0008 splitter puzzles and custom implementations, you now have the knowledge to build royalty mechanisms for any use case. Apply the patterns from this lesson to your projects. Start with simple implementations, test thoroughly, and gradually add complexity as needed. The future of digital ownership includes fair creator compensation, and you can help build it with Chialisp royalty tokens.

Chialisp Royalty Tokens FAQs

How do Chialisp royalty tokens differ from marketplace-enforced royalties?

Chialisp royalty tokens embed payment rules directly in the puzzle logic that governs the token, making royalties enforceable at the blockchain level rather than through marketplace policies. This means creators receive payments automatically during every trade regardless of which platform facilitates the transaction, eliminating the circumvention problems that plague centralized marketplace royalty systems.

Can royalty percentages be changed after minting an NFT with chialisp royalty tokens?

No, royalty percentages and creator addresses are curried into the NFT puzzle during minting and become immutable parts of the token’s code. Changing these parameters would require destroying the original NFT and minting a new one with different settings, which effectively creates a different asset with a different history.

What is CHIP-0008 and how does it work for multi-party royalty splits?

CHIP-0008 defines a standard splitter puzzle that automatically distributes incoming payments to multiple addresses according to predefined share counts. When a royalty payment arrives at a CHIP-0008 splitter, spending it requires creating outputs that match the specified distribution ratios, enabling trustless collaboration between multiple creators without intermediaries.

Do chialisp royalty tokens work with both XCH and CATs?

Standard NFT1 royalties work automatically with XCH trades through the Offers primitive. For CAT compatibility, the implementation requires additional logic to handle asset ID tracking and proper spend accounting across different token types, with some implementations pre-defining supported CATs to avoid unspendable coins from rounding issues.

How do Chia Offers enforce chialisp royalty tokens automatically?

When someone creates an offer to trade a royalty-enabled NFT, the offer file includes the NFT’s puzzle with curried royalty parameters. The Offers primitive verifies that the accepting party provides enough coins to cover both the seller’s payment and the creator’s royalty before executing the atomic swap, making it impossible to complete trades without paying royalties.

Chialisp Royalty Tokens Citations

1. Chia Network. “1.4.0 – Introducing the Chia NFT1 Standard.” https://www.chia.net/2022/06/29/1-4-0-introducing-the-chia-nft1-standard/
2. ChiaLinks. “Get Started with Chia NFTs.” https://chialinks.com/get-started-chia-nfts/
3. Decrypt. “Chia Aims to Take on Ethereum, Solana With NFTs.” https://decrypt.co/104049/chia-aims-take-ethereum-solana-nfts-will-they-blossom
4. Chia Network. “Our Vision for Chia NFTs.” https://www.chia.net/2022/05/11/our-vision-for-chia-nfts/
5. GitHub. “CHIP-0008: Splitter Puzzle by greimela.” https://github.com/Chia-Network/chips/pull/30
6. Chialisp Documentation. “NFTs.” https://chialisp.com/nfts/
7. Chialisp Documentation. “CATs.” https://chialisp.com/cats/
8. Chia Documentation. “Minting NFTs With CLI.” https://docs.chia.net/guides/nft-cli/
9. GitHub. “Chia NFT Minting Tool.” https://github.com/Chia-Network/chia-nft-minting-tool
10. Business Wire. “Chia Launches Innovative Expanded NFT Functionality in NFT1 Standard.” https://www.businesswire.com/news/home/20220629005363/en/Chia-Launches-Innovative-Expanded-NFT-Functionality-in-NFT1-Standard