How Hedera Enforces NFT Creator Royalties at the Protocol Level

Most NFT royalties have historically been a matter of agreement. A creator sets a percentage in a marketplace, a smart contract may signal it, and the platform decides whether to honor it. Protocol-level royalties take a different approach. The rule is written into the token itself and enforced by the network that processes transfers.

On Hedera, NFTs are created through the Hedera Token Service, which is a native feature of the network rather than a smart contract that each project deploys on its own. Because the token service is part of the base layer, a creator can attach fee rules to a token when it is created. When a transfer of that token runs through the token service, the network can apply those rules automatically.

This matters for creators because the royalty does not depend on a single marketplace choosing to pay it. It also matters for collectors, because the fee is visible in the token's configuration rather than hidden in a marketplace's policy page.

The model has limits, and this guide covers them in detail below. For now, the key idea is simple: on Hedera, the royalty is a property of the token, not a suggestion attached to a listing.

Hedera's token service supports two broad kinds of tokens: fungible tokens and non-fungible tokens. Both can carry custom fees, which are fee rules stored in the token's own configuration. The NFT version of this feature is what supports creator royalties.

When a token is created with a custom fee schedule, the creator names one or more fee collector accounts. Those accounts receive the fees the network collects. The schedule is part of the token's public information, so anyone can read it before buying or trading.

For NFTs, the royalty is expressed as a fraction of the value exchanged in a transfer. A fallback fee can also be set, which applies when no value changes hands. The network calculates and collects these amounts as part of the transfer.

Because this logic lives in the token service, it is the same regardless of which wallet or front end a user chooses, provided the transfer goes through the token service's standard transfer rules. That consistency is the main reason Hedera describes royalties as a protocol feature rather than a marketplace feature.

The exact field names and options can change as the network evolves, so compare any setup steps with the current Hedera developer documentation before you create a token.

Creator royalties on Hedera are built from two components: a royalty fraction and a fallback fee. They solve different problems, so it helps to understand each one.

The royalty fraction applies when an NFT is exchanged for value. Suppose a buyer pays some amount of a currency in exchange for the NFT. The fraction is applied to that value, and the resulting amount goes to the fee collector. The creator sets the fraction when the token is made, so a royalty of one tenth of the sale value would be written as a fraction representing that share.

The fallback fee applies when the transfer carries no value. Gifts, transfers between wallets owned by the same person, and some internal moves fall into this category. Without a fallback fee, these transfers would move the NFT without any payment to the creator. A fallback fee lets the creator set a small fixed charge for those cases.

It is worth reading the fallback rules carefully before you set them. A fixed fee can be a deterrent for some users, and it may be charged in a currency that not every user holds. The current documentation describes which currencies and conditions apply.

Collectors should look at both parts. A token with a large royalty fraction and no fallback may behave differently from one with a small royalty and a fixed fallback.

A creator who wants protocol-level royalties needs to plan the fee schedule before the token exists. Changing it later is limited by the keys set at creation, so careful planning matters. The steps below describe the general process. Confirm each field against the current Hedera documentation and your wallet or tooling.

1. Decide the royalty fraction you want and whether it is a fraction of value exchanged, which is the usual royalty model.
2. Decide on a fallback fee, including its amount and the currency it will be charged in.
3. Choose the fee collector account that will receive the fees. Use an account you control and can manage over the long term.
4. Decide whether to set a fee schedule key. This key determines whether the fee schedule can be updated after creation. Leaving it out can make the fees fixed, which is a stronger promise to buyers but gives you less room to adjust later.
5. Create the NFT token with the custom fee schedule attached, and record the token identifier and configuration.
6. Mint your NFTs under that token and check the token information once more to confirm the fee settings match your plan.
7. Document the royalty terms on your project page so collectors can see them before they buy.

Keep records of the keys and accounts you used. Losing control of the fee collector account or the schedule key can make it hard to manage the collection later.

Protocol-level enforcement is strong within its scope, but it does not cover every way an NFT can change hands. Understanding where it stops helps both creators and collectors avoid wrong assumptions.

The first limit is the path of the transfer. Royalties are applied when the transfer runs through the token service's standard rules. A sale that settles through a different mechanism, such as a separate contract that moves the asset outside those rules, may not trigger the fee in the same way. Marketplaces are the most common example of this issue, so check how a venue settles sales before you assume a royalty will be paid.

The second limit is the currency. A royalty expressed as a fraction of value exchanged depends on what value was exchanged and in which currency. If a sale uses a currency the fee schedule does not handle, the network's rules determine what is charged. Read the token's fee settings for currency details.

The third limit is off-network activity. A sale negotiated privately and completed outside the chain's transfer process does not have the protocol's fee applied. The creator has no protocol-level way to collect on that transfer.

The fourth limit is that protocol rules only apply to tokens created with the fee schedule. An NFT made on Hedera without custom fees has no royalty to enforce.

None of these limits mean royalties are meaningless on Hedera. They mean the royalty is strongest when both the token and the sale path follow the protocol's rules.

Royalty approaches vary widely across NFT networks. The table below compares common models at a high level. Details change as standards and platforms update, so treat it as a framework rather than a live status report.

Approach	Where the rule lives	Who typically enforces it	Main risk for creators
Hedera custom fees	In the token's fee schedule	The network, for transfers through the token service	Sales that settle outside standard transfer rules
Marketplace-set royalties	In each marketplace's policy	The marketplace	Venues can choose not to pay
Contract-signaled royalties	In the token contract's metadata	Marketplaces that read the signal	The signal is advisory, so it may be ignored
Royalty-enforcing contract pools	In the pool or market contract	The protocol's own contract logic	Depends on the pool design and which venues use it

The comparison shows why Hedera's approach is distinctive. The rule sits with the token and the network rather than with any single venue. Other ecosystems rely more on marketplace policies or contract conventions, which means enforcement can vary from one platform to the next.

Each model involves trade-offs. Protocol-level rules are consistent but limited to the protocol's transfer paths. Marketplace rules are flexible but depend on each platform's choices. Creators should decide which trade-off suits their project and tell collectors plainly which model applies.

Collectors and developers can check a token's royalty configuration before they trade. This is one of the most practical benefits of on-chain fee rules, because the information is public.

Start by finding the token identifier for the collection. Creators usually publish it on their project pages. Then open a Hedera explorer or query the public mirror node data for that token. Look for the custom fee section, which should list the royalty fraction, any fallback fee, and the fee collector account.

Next, look for the fee schedule key. If the token has one, the fee settings may be changeable by whoever controls that key. If the key is absent, the fee schedule is generally fixed once the token is created. This difference affects how much you can rely on the stated royalty over time.

Also check the token's other keys, such as those that control supply or freezing. These do not set royalties, but they affect what the creator can do with the collection after launch. Read them alongside the fee settings.

Finally, compare what you see on-chain with what the creator's documentation says. If the two do not match, ask before you buy. A clear, consistent setup is a good sign, and a mismatch deserves a closer look.

This check takes a few minutes and does not require special tools beyond a public explorer and the token identifier.

Creators get the most from protocol-level royalties when they plan the whole launch, not just the fee line. The following practices help reduce disputes and surprises.

First, state the royalty terms in plain language on your project page. Include the royalty fraction, the fallback fee, and the currency involved. Link the token identifier so buyers can check it themselves.

Second, pick a fee collector account you will still control in several years. Keep its keys secure and document who has access. Changing the collector later may be limited by the token's keys, so decide carefully.

Third, decide your schedule-key policy on purpose. A fixed schedule gives buyers certainty. An adjustable schedule gives you flexibility. Neither choice is wrong, but each should be stated openly.

Fourth, list the marketplaces where your NFTs trade and check how each one settles sales. Where a venue does not follow the protocol's transfer path, tell your community that royalties may not apply there.

Fifth, keep records of your mint transactions and configuration. These records help if you need to explain your setup later or migrate to a new collector account.

Sixth, review the current Hedera documentation before each launch, because rules and options can change.

Collectors do not need to be technical to benefit from understanding royalties. A few habits make trades more predictable.

Before buying, look up the token's custom fee settings as described earlier. Note whether a royalty is set, how large it is, and whether a fallback fee applies. This helps you calculate the total cost of a purchase and any later resale.

When you resell, the same rules usually apply. If you sell through a venue that follows the protocol's transfer path, the royalty should be applied. If you sell through a venue that does not, the creator may not receive the fee, and that is a choice the venue made rather than a rule the token imposed.

Use the marketplace's own help pages to confirm how it handles royalties. Some venues describe their settlement process clearly, and others do not. A venue that is vague about royalties may be harder to rely on for consistent outcomes.

Also confirm the currency a sale uses. Fees are calculated in relation to the value exchanged, so the currency matters for the amount you will pay.

Finally, treat any listing that promises royalties with suspicion until you confirm the token's settings on-chain. Keep your wallet software updated and never share your recovery phrase with anyone, including people who claim to represent a creator or marketplace.

This guide is written from the stable design of Hedera's token service and the general way custom fees work. Public reporting used for this page were mostly general material about NFT royalties, creator guides, and Hedera's broader positioning. They did not provide a detailed, current specification of Hedera's royalty rules, fee currencies, or key behavior.

That gap matters. Fee amounts, supported currencies, key options, and transfer rules are the kind of detail that can change, so the safest approach is to confirm them directly in the current Hedera documentation and on a public explorer for the specific token you care about.

Some background reading also helps. General guides on NFT royalties explain why creators have pushed for enforceable fees, and they show how different ecosystems have approached the problem. Those explanations are useful for context, though the specific rules of any one network should come from that network's own documentation.

When you verify a claim about Hedera royalties, ask three questions. Does the token's on-chain configuration show the fee? Does the transfer path I am using follow the token service's standard rules? Has the creator or the network documented any change since the token was launched?

If you cannot answer all three with confidence, treat the royalty as uncertain and plan your trade or launch accordingly.