Skip to content

community-proposal doc update #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
beyzaes wants to merge 1 commit into
base: main
Choose a base branch
from
Open

community-proposal doc update #56

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions docs/community-proposals.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,29 +7,38 @@ slug: /community-proposals

## tokenCreator

We support the `tokenCreator` method to help ensure more secondary marketplaces honor creator fees, and we would like to encourage other NFT projects to do the same.
We propose a small, standard accessor that exposes the original creator of an NFT. This makes it easier for marketplaces and other platforms to reliably determine where creator fees should go.

`tokenCreator` would be needed both for secondary markets but also for terminal and other platforms trying to reliably get the of creator

We're thinking of proposing a new EIP with this change. Let us know your thoughts in the [Discord](http://discord.foundation.app)!
Suggested signature:

```solidity
function tokenCreator(uint256 tokenId) public view returns (address payable);
function tokenCreator(uint256 tokenId) external view returns (address payable);
```

Why this helps
- Provides a single, unambiguous on-chain source for the creator address.
- Simplifies fee routing for secondary marketplaces and platforms (e.g., terminals, aggregators).
- Reduces need for off-chain heuristics or metadata parsing that can be unreliable.

We are considering proposing this as an EIP. Feedback and discussion are welcome — join us on Discord: http://discord.foundation.app

## Fees

The Foundation contracts follow the OpenSea spec, which means in their next version that honors fees onchain, it guarantees those fees go to creators.
Foundation contracts follow the widely-used OpenSea fee spec, exposing creators and fee basis points via the `HasSecondarySaleFees` interface. In implementations that honor on-chain fees, this guarantees those fees go to creators.

`HasSecondarySaleFees` is:
OpenSea-style interface:

```solidity
function getFeeRecipients(uint256 id) public view virtual returns (address payable[] memory);
function getFeeRecipients(uint256 id) external view returns (address payable[] memory);

function getFeeBps(uint256 id) public view virtual returns (uint256[] memory);
function getFeeBps(uint256 id) external view returns (uint256[] memory);
```

and the interface is registered with `ERC165`.
This interface should be registered with ERC165 so marketplaces can detect support programmatically.

Ideas for a new EIP
- A compact, minimal interface that combines recipient and fee info into a single call for gas efficiency.
- A standardized way to express multiple recipients and priority (creator vs platform) that is simple to detect via ERC165.
- Backwards-compatible mapping from existing OpenSea-style interfaces to a more efficient spec.

We have some ideas though for an EIP that would make for a more efficient solution, and we're thinking of trying to make this an NFT community standard. What do you think? Feel free to join the conversation in the [Discord](http://discord.foundation.app).
If you have thoughts or concrete proposals, please join the conversation in the Discord: http://discord.foundation.app