TEP-66
Royalty standard for NFTs on TON: the percentage of secondary sales marketplaces pay to the collection creator. Formalised through the royalty_params get-method.
Aliases: tep 66, ton nft royalty, royalty standard
TEP-66 is TON’s NFT royalty standard. It defines how a collection’s creator collects a share of secondary sales on marketplaces. On the protocol level it is just one get-method and a response format — simple, but effective.
The mechanism
TEP-66 adds one required get-method on top of TEP-62:
royalty_params() returns (numerator, denominator, destination)- numerator / denominator. Fraction, e.g. 5/100 = 5%.
- destination. Address marketplaces should send royalties to.
The method is implemented at the collection level (NFT Items usually proxy the request to their parent). When closing a sale, a marketplace calls this method and automatically splits the proceeds between seller and royalty destination.
What matters
- It’s on-chain enforcement by convention. The blockchain can’t technically force a marketplace to pay royalties — the platform decides. But marketplaces that don’t follow TEP-66 are ignored by the ecosystem.
- Royalty ≠ marketplace fee. They’re separate flows: the platform takes its own fee (typically 2–5%), and pays the royalty on top, out of the remaining price.
- Missing get-method. If a collection doesn’t implement
royalty_params, marketplaces either treat royalty as 0 or refuse to list. So you should implement it even when the royalty itself is zero.
A worked example
An NFT with 5% royalty sells for 100 TON on Getgems:
| Recipient | Amount |
|---|---|
| Creator (TEP-66 destination) | 5 TON |
| Marketplace (Getgems fee) | 5 TON |
| Seller | 90 TON |
Exact percentages depend on the platform.
Limits
TEP-66 is honoured by all major TON marketplaces (Getgems, Disintar) and supported by wallets. Royalties don’t apply to peer-to-peer sales outside marketplaces — that’s a technical limitation, not a policy choice.