# NFT Royalty Split Calculator for Collaborators | NFT Academy

> Divide NFT royalty revenue across collaborators, validate shares to 100%, and see exactly what each person receives per sale. Free browser calculator.

Source: https://thenftacademy.com/tools/royalty-split-calculator
Site: The NFT Academy (https://thenftacademy.com)

---
Free tool

## Royalty split calculator

Model how a sale divides across a marketplace fee, the creator royalty and every collaborator, and catch shares that don’t add to 100% before they’re hardcoded into a contract you can’t change.

Runs entirely in your browser. Nothing you type is sent anywhere.

The sale

Sale price

ETH

ETH price

$

Creator royalty

%

Typically 0–10%.

Marketplace fee

%

Who gets the royalty

%

%

%

Shares total 100% ✓

Where one sale goes

Sale price · 1.0000 ETH · $3,000.00

Marketplace fee · −0.0250 ETH

Creator royalty pool · 0.0500 ETH · $150.00

Seller keeps · 0.9250 ETH · $2,775.00

Royalty split

Artist 50% of the royalty · 0.02500 ETH · $75.00

Developer 30% of the royalty · 0.01500 ETH · $45.00

Community treasury 20% of the royalty · 0.01000 ETH · $30.00

Per sale, at the royalty rate above. Multiply by expected secondary sales volume to model a collection.

Royalties are not automatically enforced by every marketplace. Several major venues made them optional, so treat secondary-sale royalty income as a best case rather than a given. On-chain splitter contracts are the only way to make a split binding.

### Why get this right before you deploy

A payment splitter contract takes the shares you give it and distributes every incoming payment accordingly, forever. If the shares are wrong, the money goes to the wrong places on every sale, and in most implementations there’s no way to fix it without deploying a new contract and migrating. This is a ten-minute check that prevents a permanent problem.

### The two numbers people confuse

There’s a difference between **the royalty rate** and **the split**. The royalty rate is what percentage of each secondary sale goes to the creator side at all — 5%, say. The split is how that 5% is then divided among the people who made it. A collaborator with a "50% share" isn’t getting 50% of the sale; they’re getting 50% of 5%, which is 2.5% of the sale. The calculator above shows both, because this misunderstanding causes real arguments.

### What a sensible split looks like

| Role | Typical share | Reasoning |
| --- | --- | --- |
| Artist | 40–60% | The work is the product; usually the largest share |
| Developer | 15–30% | Contract, minting site, infrastructure |
| Community / treasury | 10–25% | Ongoing costs, and the thing that keeps a project alive after launch |
| Marketing / operations | 5–15% | Only if someone is doing this work |

These are conventions, not rules. The one structural point worth making: leaving nothing for a treasury is the most common mistake. Projects have running costs — hosting, metadata storage, gas for administrative transactions, and a split that pays everything out to individuals on day one leaves nothing to fund them.

### Royalties are a convention, not a guarantee

This is the honest caveat, and it matters more than any percentage above. Royalties are not enforced by the Ethereum protocol or by the ERC-721 standard. They’re a payment marketplaces *choose* to route to the creator, and several large ones stopped doing so. If your project’s economics depend on secondary royalties covering costs, build the model assuming a substantial fraction never arrives.

### Common questions

##### What is a normal royalty percentage?

Historically 5–10%, with 5% the most common default. Anything above 10% is unusual and tends to suppress secondary trading, because it comes straight out of the seller's proceeds every time the piece changes hands.

##### Are royalties actually paid?

Not reliably. Royalties were never enforced at the protocol level — they’re a convention marketplaces chose to honour. Several major venues made them optional, so a meaningful share of secondary volume now pays the creator nothing. Treat royalty income as a best case, not a projection.

##### How do I make a split binding?

With an on-chain payment splitter contract that receives the royalty and distributes it by fixed shares. A handshake agreement between collaborators isn’t enforceable once money is moving automatically. OpenZeppelin publishes a widely used PaymentSplitter implementation.

##### Can I change the split after deployment?

Only if you built that in. A plain splitter with hardcoded shares is immutable. If shares may need to change, a collaborator leaving, a treasury allocation shifting, that has to be an explicit, governed feature from the start.