EIP-4910: Royalty Bearing NFTs(Non Fungible Tokens).

Firstly, What is Ethereum Improvement Proposal (EIP)? it is a document used to propose new changes to the ethereum network and its surrounding ecosystem.

Secondly, what are NFTs (non-fungible tokens)? NFTs are based on the ERC-721 standard (EIP-721), it is a unique cryptographic token on a blockchain, that can serve as digital certificate of authenticity & ownership of a digital and physical real world assets, they can also not be replicated It’s like owning a sword from a video game — you can’t touch it, but it’s there, online. And it’s yours.

Royalty Bearing NFTs (EIP- 4910).

This is an extension of the ERC-721 standard (NFTs) proposed to correctly define, process, pay onchain NFT royalties, It directly connects the NFTs and royalties in a smart contract architecture. The EIP-4910 solves the problem of trust issues on the application (“marketplace”), so there needs to be a more trustless way to manage the royalties, so EIP-4910 aims to prevent central authorities from manipulating payments to those who are legally entitled to them.

EIP-4910 was motivated to solve the lack of enforceable royalties and provides for automatic onchain distribution of royalties to creators and rights holders whenever and wherever their NFTs are resold

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”

these keywords exist so that all developers follow the same standard approach when implementing the specification.

This proposal adds some new ideas to ERC-721 NFTs

Royalty Acccount (RA): It is identified by an account identifier, It is attached to each NFT through it tokenId and it consist of sub-acccounts(individual accounts or other RAs). Only individual accounts can carry a balance that can be paid out and all RA balances must be allocated to individual accounts. Account Type: specifies if an RA Sub Account belongs to an individual (user) or is another RA. If there is another RA as an RA Sub Account, the allocated balance needs to be reallocated to the Sub Accounts making up the referenced RA. Royalty Split: The percentage each Sub Account receives based on a sale of an NFT that is associated with an RA Royalty Balance: The royalty balance associated with an RA. Sub Account Royalty Balance: The royalty balance associated to each RA Sub Account Token Type: Token Type is given as either ETH or the symbol of the supported utility tokens such as DAI Asset ID: this is the token id that belongs to the RA. Paarent: This indicates which tokenId is immediate parent of the tokenId which an RA belongs.

NOTE: Royalty Account is defined as a collection of Royalty Sub Accounts linked to a meta account. This meta account is comprised of general account identifiers particular to the NFT it is linked to such as asset identifier, parent identifier

Data Structures

In other to make NFTs work with Royalty Accounts (RAs) and track payments, the system needs a some data structures:

Royalty Accounts and Sub-Accounts: This is like a main account with smaller linked accounts under it, to manage who gets royalties.

Token-to-Royalty Link: Each NFT (tokenId) is connected to a specific Royalty Account so royalties go to the right place.

Parent-to-Child NFT Relationships: Tracks which NFTs are derived from or connected to other NFTs (like family tree for tokens).

Token Types and Balances: Keeps a list of NFT types and their last known balances — useful for trading and paying royalties.

Registered Payments: Keeps track of payments that need to be made. Once a payment is made through the system, it’s removed from this list.

NFTs for Sale: A list of all NFTs that are currently available to sell.

Royalty Account Functions:

These define how to read, update, and delete Royalty Account data, and since the account is created during NFT minting, no separate creation function is needed.

Minting of a Royalty-Bearing NFT:

When an NFT is created, a Royalty Account is automatically linked to it, its owner, and any parent NFT, using a safe minting process with specific rules.

Listing NFTs for Sale and Removing a Listing:

Approved users can list NFTs for sale and remove them later for direct purchases without using an exchange.

Payment Function from Buyer to Seller: To ensure royalties are paid, buyers send payment directly to the NFT contract, which then distributes funds to the seller and royalty recipients.

ERC-20 Token Payment: The buyer approves the NFT contract to use their ERC-20 tokens and completes the purchase by calling the payment function.

ETH (Non-ERC-20) Payment: The buyer sends ETH to the NFT contract along with the IDs of the NFTs being purchased so the contract can process the payment.

Requirments for EIP-4910:

• [R1] Every Royalty Account must have at least one sub-account.
• [R2] Every Royalty Account ID must be unique.
• [R3] Every NFT must be linked to a Royalty Account.
• [R4] Each child NFT must be directly linked to its parent NFT.
• [R5] The contract must keep a list of allowed payment tokens.
• [R6] The contract must track its last known balance for each allowed token.

More on the Requiments for EIP-4910: https://medium.com/@Solo_Dev/requirements-for-eip-4190-a90c7525d453

This EIP is backwards compatible to the ERC-721 standard introducing new interfaces and functionality but retaining the core interfaces and functionality of the ERC-721 standard and a full test suite is part of the reference implementation.

Security Consideration

• Payments and Payouts: Protects how money is paid, reversed, and withdrawn so funds are not stolen or stuck.
• Circumventing Royalties: Prevents creators from being cheated out of royalties through indirect or off-chain tricks.
• Phishing Attacks: Protects users from being tricked into approving or selling their NFTs unintentionally.

In Conclusion, besides the usage of professional security analysis tools, it is also recommended that each implementation performs a security audit of its implementation.