On-Chain NFT Royalties: Build an ERC-2981 Token

Before ERC-2981, each marketplace implemented royalties in its own way: OpenSea stored a list off-chain, Rarible used its own contract, LooksRare had its own scheme. As a result, NFT creators lost up to 30% of secondary sale revenue due to manual registration. We develop smart contracts with the built-in ERC-2981 standard, guaranteeing automatic royalties on all popular platforms—OpenSea, Rarible, LooksRare, Blur, and X2Y2. We handle everything from smart contract prototype to security audit and deployment in the chosen network. ERC-2981 has become the industry standard for on-chain royalties, and we help implement it with minimal gas costs and maximum transparency. Savings on marketplace commission can reach 30%. Our team has 5+ years of Web3 experience and has performed 15+ audits, enabling us to quickly find the optimal solution for each project. On average, a creator saves $2,000–$5,000 per month on manual administration.

Learn more about the standard: EIP-2981

Why ERC-2981 Became the Standard for On-Chain Royalties

Before the standard, creators had to register separately on each marketplace. ERC-2981 makes royalties portable: deploy your contract, and all platforms supporting the interface automatically apply your terms. This saves hundreds of hours of manual administration. On-chain royalties with ERC-2981 speed up integration with new marketplaces by 5x compared to the off-chain approach.

Comparison: On-Chain vs Off-Chain Royalties

Off-chain was popular, but creators lost control. On-chain with ERC-2981 is the industry standard we recommend to all clients.

How ERC-2981 Works

The standard adds one function to the contract:

function royaltyInfo( uint256 tokenId, uint256 salePrice ) external view returns (address receiver, uint256 royaltyAmount); 

When a sale occurs, the marketplace calls royaltyInfo(tokenId, salePrice) and gets the receiver address and royalty amount. That's it. The standard is intentionally minimal—it does not enforce payment (enforcement is off-chain), it only provides the data.

Basic implementation via OpenZeppelin:

import "@openzeppelin/contracts/token/common/ERC2981.sol"; contract MyNFT is ERC721, ERC2981 { constructor() ERC721("MyNFT", "MNFT") { _setDefaultRoyalty(msg.sender, 500); // 500 basis points = 5% } function setTokenRoyalty(uint256 tokenId, address receiver, uint96 feeNumerator) external onlyOwner { _setTokenRoyalty(tokenId, receiver, feeNumerator); } } 

feeNumerator is the numerator relative to _feeDenominator() (default 10000). So 500 = 5%, 250 = 2.5%, maximum 10000 = 100% (not recommended). We optimize the contract for minimal gas consumption on royaltyInfo calls.

Advanced Royalty Patterns

Splitter Royalties for Multiple Recipients

The standard supports only one receiver. To split among creator, team, and foundation, you need an additional contract. Two approaches:

• PaymentSplitter: The receiver in ERC-2981 points to a PaymentSplitter contract (OpenZeppelin). The marketplace transfers the entire amount to the splitter, which distributes it according to shares. Simple, proven, but extra gas on release.
• Push royalty splitter: A mechanism built into the NFT contract that automatically distributes to addresses on each incoming transfer. Saves one call but complicates the contract.

Dynamic Royalties

ERC-2981 allows royaltyInfo to return different values for different tokenIds. This opens possibilities:

• Decreasing royalty with sale price increase (progressive scale)
• Different rates for different token categories (tier system)
• Zero royalty for primary sale, 5% for secondary

Example of dynamic royalties with a progressive scale:

function royaltyInfo(uint256 tokenId, uint256 salePrice) public view override returns (address, uint256) { uint96 rate; if (salePrice <= 1 ether) rate = 500; // 5% up to 1 ETH else if (salePrice <= 10 ether) rate = 300; // 3% up to 10 ETH else rate = 100; // 1% above 10 ETH return (_royaltyReceiver, (salePrice * rate) / _feeDenominator()); } 

How to Implement Dynamic Royalties with Flexible Rates

Choosing between a basic implementation, a splitter, and dynamic rates depends on your business model. If you have a single creator and fixed commission, a basic ERC-2981 is sufficient. For teams with multiple recipients, use PaymentSplitter. To incentivize trading, implement dynamic rates. We'll help analyze your case and choose the optimal solution. Get a free project assessment within 24 hours—contact us.

Our Process

1. Analysis: We examine royalty requirements, trading scenarios, target audience.
2. Design: We select the architecture (basic, splitter, dynamic) and prepare specifications.
3. Development: We write the contract in Solidity 0.8.x, use Foundry for testing and verification.
4. Testing: Coverage >95%, fuzzing with Echidna, reentrancy checks, and gas optimization.
5. Audit: Internal and external security audit (slither, formal verification).
6. Deployment: Deploy on Ethereum/Polygon, verify on Etherscan, configure supportsInterface.
7. Support: Monitoring, updates on network forks, integration consulting.

What's Included in Development?

• Source code of the contract with tests (GitHub repository)
• Deployment and configuration documentation
• Deployment in the chosen network (Ethereum, Polygon, Arbitrum, BNB Chain)
• Contract verification on blockchain explorer
• Integration with marketplaces (OpenSea, Rarible, LooksRare)
• Security audit (vulnerability report)
• Access to private repository for future modifications
• One month of support after deployment

Timeline Estimates

Cost is calculated individually based on complexity. Get an estimate within one day – contact us, and we'll prepare a proposal. Our team has 5+ years of Web3 experience, has performed 15+ smart contract audits, and has deployed dozens of ERC-2981 tokens for clients from the US, Europe, and Asia. Contact us to discuss the architecture.