Royalty Forwarding

The primary function is to enforce creator royalties on secondary NFT sales, bypassing marketplaces that have made them optional. The smart contract intercepts the sale proceeds and automatically splits the payment, ensuring the creator's share is sent directly to their wallet before forwarding the remainder to the seller.

• Key Mechanism: Uses a receive() or fallback function to capture incoming ETH or other native tokens.
• Example: On a 10 ETH sale with a 5% royalty, the contract sends 0.5 ETH to the creator and 9.5 ETH to the seller.

Royalty forwarding enables complex revenue-sharing models for decentralized organizations. Instead of a single creator, funds can be split among multiple parties, such as a DAO treasury, core developers, and community reward pools.

• Use Case: An NFT project's DAO uses a forwarding contract to direct 2% of all secondary sales to its treasury for operational funding and 3% to a staking reward pool for holders.
• Implementation: Achieved via a PaymentSplitter-style contract or custom logic that calculates and distributes shares.

Contracts can embed affiliate or referral logic to reward promoters. A portion of the sale is forwarded not just to the creator, but also to the wallet that facilitated the transaction.

• Process: The contract checks for a valid referral code or affiliate address attached to the transaction and allocates a predefined percentage of the sale price to that address.
• Benefit: Creates a transparent, trustless incentive system for community-driven marketing and sales.

Advanced implementations facilitate cross-chain royalty payments. When an NFT is bridged or sold on a different blockchain, a forwarding contract on the destination chain can handle the fee distribution using message-passing protocols like LayerZero or CCIP.

• Workflow: Sale occurs on Chain B. The contract on Chain B calculates royalties, may lock funds, and sends a message to a controller contract on Chain A to release payments to the creator's wallet on the origin chain.
• Complexity: Requires secure cross-chain communication and often involves wrapped asset representations.

Forwarding contracts can implement dynamic royalty rates that change based on predefined conditions, moving beyond static percentages. This allows for programmable business logic.

• Examples:
  • Time-based: Royalty decreases after a certain date to encourage early trading.
  • Holder-based: Royalty is waived for sales between wallets that have held the NFT for over a year.
  • Volume-based: Royalty rate adjusts based on the sale price or total trading volume.
• Flexibility: Logic is encoded directly into the contract's payment forwarding function.

As a standard-agnostic solution, royalty forwarding provides a consistent enforcement layer across diverse and fragmented NFT marketplaces. It creates a contract-level guarantee that is independent of any single marketplace's policy.

• Problem Solved: Marketplaces like Blur, OpenSea, and Magic Eden have different royalty enforcement stances, creating uncertainty for creators.
• Solution: The NFT's core transfer logic mandates the royalty payment via the forwarding contract, making enforcement a property of the asset itself rather than the platform.

Royalty forwarding is enforced directly by smart contract logic, not marketplace policy. The protocol intercepts a portion of the sale proceeds and routes it to the creator's wallet before the seller receives payment. This makes royalties programmatically guaranteed and resistant to marketplace opt-outs. Key methods include:

• Transfer hooks: Code that executes on every NFT transfer.
• Royalty registry: A reference contract that stores and enforces fee settings.

EIP-2981 is the foundational Ethereum standard for communicating royalty information. It defines a royaltyInfo function that returns the recipient address and the royalty amount for a given sale price. While it standardizes the signal for royalties, it does not enforce payment. Royalty forwarding protocols use this data but add the enforcement layer, making the standard actionable across all marketplaces that integrate the protocol.

By guaranteeing secondary sales revenue, royalty forwarding transforms NFT projects from one-time mints into sustainable creator economies. It enables long-term funding for:

• Project development and roadmap execution.
• Community treasury funding.
• Ongoing artistic work and collaborations. This shifts the economic model from pure speculation to value-aligned patronage, where collectors directly support creators they believe in with every trade.

For royalty forwarding to be effective, marketplaces must integrate the enforcing protocol. Leading marketplaces like Blur and OpenSea have implemented support, creating a network effect. Integration typically involves the marketplace contract checking the relevant registry or hook before finalizing a sale, deducting the royalty, and sending it directly to the designated address. Widespread adoption creates a level playing field where creator fees are the default.

The two primary technical approaches are:

• Transfer Hooks: Function calls that are triggered automatically upon an NFT transfer (e.g., using ERC-721's _beforeTokenTransfer). The hook contains the logic to calculate and forward the fee.
• Royalty Registries: A single, canonical smart contract that stores fee settings for many collections. Marketplaces query this registry to determine the correct fee and recipient for any NFT sale, then execute the payment split within the transaction.

Royalty forwarders are often implemented as upgradeable proxy contracts to allow for logic improvements. This introduces the central risk of a malicious upgrade by the contract owner, which could:

• Divert funds to a new, unauthorized address.
• Permanently lock or destroy funds.
• Change critical validation logic.

Security relies on transparent governance and timelock controls on the proxy admin.

The forwarder must correctly identify the legitimate royalty recipient and amount for each transaction. Key vulnerabilities include:

• Incorrect payment splitting due to flawed logic.
• Reentrancy attacks if external calls are made before state updates.
• Spoofing attacks where a malicious contract mimics a legitimate NFT sale to claim royalties.

Secure implementations use checks-effects-interactions patterns and validate sale data against a trusted source, like the marketplace contract.

A royalty forwarder acts as a trusted intermediary for all payments. This creates a single point of failure and trust. Considerations include:

• Private key compromise of the deployer or admin.
• Operator censorship or selective payment blocking.
• Dependency on the forwarder's liveness; if it halts, royalties stop.

Decentralized alternatives or multi-signature controls can mitigate these risks.

Forwarders increase the attack surface by interacting with multiple external systems. Security audits must cover:

• Marketplace integrations: Ensuring correct calldata parsing from each supported platform (OpenSea, Blur, etc.).
• Token standards: Handling edge cases in ERC-721 and ERC-1155 transfers.
• Cross-chain bridges: If operating across chains, verifying the security of the message-passing layer (e.g., LayerZero, Wormhole). Each integration point is a potential vector for exploitation.

The forwarding transaction itself can be a target for Maximal Extractable Value (MEV). Risks include:

• Sandwich attacks on royalty token swaps if the forwarder automatically converts funds.
• Frontrunning the distribution transaction to manipulate oracle prices.
• Gas griefing where an attacker causes the forwarder to fail its transaction, blocking the payment.

Using private mempools (e.g., Flashbots) or batching distributions can reduce exposure.

A critical threat is an attacker tricking the forwarder into sending funds to the wrong address. This can be achieved through:

• Signature replay attacks on off-chain authorization messages.
• Malicious setRoyaltyRecipient calls if permissions are incorrectly managed.
• Domain spoofing in EIP-712 typed data signatures for permission updates.

Defenses include using nonces in signatures, robust access control (like OpenZeppelin's Ownable), and multi-factor changes for critical addresses.