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.

Why does NFT marketplace development require a comprehensive approach?

We see that at first glance, an NFT contract looks simple: ERC-721, mint(), IPFS for metadata — that's it. In practice, it's this 'simplicity' that hides most problems — from bots buying out the entire mint in the first block to broken royalties on the secondary market. We often hear: Make a collection like others in a week — and a month later it turns out gas has tripled due to an unoptimized for loop, or OpenSea cannot see metadata after reveal. We know each of these pitfalls and build processes to avoid them.

Over 5 years of working with blockchains, we have implemented 40+ NFT projects, including marketplaces with dynamic attributes and cross-chain bridges. We have accumulated a library of proven templates — some of which we break down below.

Which standard to choose: ERC-721 or ERC-1155?

ERC-721 — each token is unique, one owner. Suitable for collections where each NFT has individual attributes and a direct owner → tokenId mapping.
ERC-1155 — multi-token standard: one contract holds both fungible and non-fungible tokens. It uses balanceOf(address, tokenId) instead of ownerOf(tokenId). A single transaction can transfer multiple different tokens via safeBatchTransferFrom. This saves gas on bulk operations — important for game items, tickets, edition collections. ERC-1155 is 2–3× more gas-efficient than ERC-721 for batch transfers.

Specific case: a game project with 50 types of items, each with a supply of 10,000. ERC-721 — 500,000 unique tokens, huge overhead on mappings. ERC-1155 — 50 tokenIds, balanceOf per player. Gas per transfer is 2–3 times lower, contract deployment is cheaper. For such tasks, we use OpenZeppelin ERC-1155 with custom modifications.

Metadata: on-chain vs IPFS vs centralized

The standard route is tokenURI() returning a link to a JSON with fields name, description, image, attributes. Three storage options:

• Centralized server — cheapest and most flexible. Risk: server goes down, company closes — NFT loses metadata. Not suitable for collections claiming long-term value.
• IPFS + Pinning — content-addressed storage, the link is bound to the content hash. Pinata or NFT.Storage provide pinning. Important: IPFS does not guarantee availability by itself — an active pinning service is needed. If it shuts down, data may disappear if no one keeps a copy.
• On-chain metadata — base64-encoded SVG or JSON directly in tokenURI. Maximum reliability, but expensive: for a collection of 10,000 tokens, gas costs may exceed $5,000. Suitable for generative art projects where visuals are generated from on-chain attributes (Nouns, Loot).

For most collections, we choose IPFS with Pinata for images + on-chain attributes for traits — a good balance. We validate files against a JSON Schema before upload; a typical mistake is unescaped quotes, causing marketplaces to display a blank screen.

{
  "name": "Token #1",
  "description": "A unique NFT",
  "image": "ipfs://QmHash/image.png",
  "attributes": [{"trait_type": "Background", "value": "Red"}]
}

Dynamic NFT: metadata that changes

Dynamic NFT updates metadata in response to external events — match results, character levels, real-world data via Chainlink. Architecturally, it's a combination: the smart contract stores state → tokenURI() generates metadata from the state on-chain. Caching problem: OpenSea and other marketplaces aggressively cache. The standard invalidation mechanism is a MetadataUpdate(tokenId) event from ERC-4906. OpenSea listens to this event and clears the cache. Without it, updated metadata may not appear for weeks.

Chainlink Automation (formerly Keepers) for automatically updating state on the contract on a schedule or condition — a standard solution for dynamics.

How to protect mint from bots?

Allowlist via Merkle tree — standard. The list of addresses is hashed into a Merkle root, stored in the contract. During mint, the user provides a Merkle proof — the contract verifies without storing the full list. We use OpenZeppelin MerkleProof library.

Reveal mechanism — on mint, a placeholder is issued; real traits are revealed after the sale ends. Otherwise, bots can scan pending transactions and snipe rare traits via frontrunning. But reveal requires a commitment scheme — the random seed must be fixed before mint or use Chainlink VRF.

Chainlink VRF for fair randomization of traits. VRF request at mint → callback with verifiable random number → assign traits. This adds ~2 transactions and latency but guarantees fairness. Chainlink VRF v2.5.

Rate limiting — require(mintedPerWallet[msg.sender] < maxPerWallet). Does not protect against multi-wallets but raises attack cost. For premium projects, we often add proof-of-work directly in the contract (via EIP-2612 signatures).

Royalties: the real market state

ERC-2981 — on-chain royalty standard. The contract returns (recipient, amount) for any sale price via royaltyInfo(tokenId, salePrice). Marketplaces query this on each sale. Problem: adherence to royalties is voluntary for marketplaces. Blur launched with zero royalties, triggering a wave of other platforms. The situation has partially stabilized: OpenSea supports ERC-2981, Blur added optional ones. Royalty payments can represent 5–10% of secondary sale volume, so getting them right matters.

Attempts to enforce royalties on-chain by restricting transfers only to approved marketplaces (operator filtering) were proposed by OpenSea via OperatorFilterRegistry. This breaks composability — you cannot transfer an NFT through a custom contract. Most serious projects have abandoned this approach. For projects where royalties are critical, we build a custom marketplace within the ecosystem plus an incentive structure for users to trade there.

Lazy minting and gas-free mint

Gas-free mint via signature: the creator signs a voucher (tokenId, tokenURI, price, signature), the buyer provides the voucher in mint() — the contract verifies the signature via ECDSA.recover() and mints. Works on OpenSea via their Seaport protocol. Seaport is an optimized contract with minimal gas usage. Understanding its mechanics is important when integrating custom marketplace logic.

Stack for NFT projects

• Contracts: Solidity 0.8.x, OpenZeppelin ERC721Enumerable or ERC721A (Azuki) for gas-optimized batch mint, ERC1155 from OpenZeppelin
• VRF and automation: Chainlink VRF v2.5, Chainlink Automation
• Storage: Pinata (IPFS pinning), NFT.Storage, Arweave for permanent storage
• Marketplace: OpenSea Seaport protocol, custom integration
• Frontend: wagmi v2 + viem, RainbowKit for wallet connection, React + TypeScript

Development process

1. Mint mechanics design — allowlist, public sale, price curve (Dutch auction or fixed), limits per wallet
2. Contracts — with Foundry fuzz tests on mint limits, Merkle proof verification, royalty calculations
3. IPFS deployment — upload metadata and images before reveal, pin on at least two services
4. Reveal — if using Chainlink VRF, test on testnet mandatory: VRF subscription must be funded with LINK tokens
5. Marketplace integration — verify collection on OpenSea, configure royalties, test MetadataUpdate events
6. Deployment and monitoring — Tenderly for reentrancy detection, Etherscan API for contract verification, set up event alerts

Deliverables

• Source code of smart contracts (Solidity, Rust for Solana) with comments
• Test suite (Foundry/Hardhat) with ≥90% coverage
• Deployment documentation and integration instructions
• Access to pinning services (Pinata/Pinfluence)
• Metadata generation scripts (Python/JS)
• Support during marketplace verification
• 30 days of technical support after deployment

Timeline

Cost is calculated individually after auditing your task. Send a brief with your project description — we will provide a transparent estimate within 3 business days. For regular clients, there is a flexible discount system on batch orders. If you need a gas-optimized contract, order a free gas analysis. Get a consultation on marketplace architecture — leave a request, and we will evaluate your project in three days.