The NFT Academy

Free tool

Royalty split calculator

Model how a sale divides across a marketplace fee, the creator royalty and every collaborator — and catch shares that do not add to 100% before they are hardcoded into a contract you cannot change.

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

The sale

ETH
$
%

Typically 0–10%.

%

Who gets the royalty

%
%
%

Shares total 100% ✓

Where one sale goes

Sale price1.0000 ETH · $3,000.00
Marketplace fee−0.0250 ETH
Creator royalty pool0.0500 ETH · $150.00
Seller keeps0.9250 ETH · $2,775.00

Royalty split

Artist50% of the royalty0.02500 ETH · $75.00
Developer30% of the royalty0.01500 ETH · $45.00
Community treasury20% of the royalty0.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 is 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 is 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" is not getting 50% of the sale; they are 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

RoleTypical shareReasoning
Artist40–60%The work is the product; usually the largest share
Developer15–30%Contract, minting site, infrastructure
Community / treasury10–25%Ongoing costs, and the thing that keeps a project alive after launch
Marketing / operations5–15%Only if someone is genuinely 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 are 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 are 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 is not 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.