NFT marketplaces beyond the hype: building royalty logic that lasts

By Marco Lopes · March 18, 2021 · Blockchain & Web3

NFT marketplaces are attracting attention, but attention is not a settlement architecture. Behind every promise that a creator will receive a percentage of future sales, we need rules that explain who pays, who receives, which transactions qualify, and what happens outside our application.

At Kordspace, we work across software, AI, Web3, hardware, and design as a remote collaborative studio. When we approach an NFT marketplace, we see more than a minting screen. We see a financial workflow, a rights communication problem, and an operational system that must remain understandable after launch.

Our starting point is simple: royalties are only as dependable as the mechanisms honoring them. A percentage stored beside a token does not automatically make every future transfer produce a payment.

Here is how we would build royalty logic today without confusing a product promise with a blockchain guarantee.

Start with the promise, not the contract

Before choosing a token contract, we write the royalty policy in ordinary language. We need agreement on what counts as a sale, whether primary sales and secondary sales follow different rules, and whether the royalty applies to the gross price or an amount remaining after fees.

We also identify the beneficiary. That might be one creator wallet, several collaborators, or a payout contract distributing funds among contributors. The account uploading an asset should not automatically become the permanent royalty recipient without an explicit decision.

We separate three concepts that are often presented together:

• Ownership: which address controls the token.
• License: what rights the buyer receives regarding the associated work.
• Royalty policy: what participating sale mechanisms pay to designated recipients.

Buying a token does not inherently transfer copyright. Paying a royalty does not establish that the seller had permission to mint the work. Our interface and terms need to communicate those distinctions.

Be honest about enforcement boundaries

ERC-721 and ERC-1155 give us useful token interfaces, but neither automatically charges a creator royalty on every resale. A token transfer generally does not reveal whether money changed hands, how much was paid, or whether payment occurred elsewhere.

If our marketplace contract controls settlement, we can require the appropriate royalty before completing a sale through that contract. We cannot honestly extend that guarantee to every external marketplace, private arrangement, or direct wallet transfer.

Restricting transfers to approved routes can strengthen control, but it introduces trade-offs. We may reduce compatibility with wallets, custody arrangements, and other applications. We also need to distinguish a sale from a gift, a wallet migration, or a deposit into another contract.

For many projects, the sensible initial promise is narrower: our marketplace enforces its published royalty policy, while compatible external marketplaces may honor the same information. We would rather explain that boundary clearly than advertise perpetual income that the system cannot ensure.

Model royalties as durable data

We keep royalty configuration separate from presentation metadata. An image URL or descriptive JSON file may help display an asset, but our settlement contract should not depend on fetching a website to determine who gets paid.

A practical configuration includes a recipient address, a rate, and a defined scope. We decide whether that scope is collection-wide, token-specific, or a collection default with explicit token overrides. We also document which rule wins when more than one exists.

We prefer integer basis points for percentage calculations. One basis point is one hundredth of a percent, so a 7.5% royalty becomes 750 basis points. We validate limits at configuration time and again wherever combined deductions could exceed the sale amount.

Mutability deserves particular care. If an administrator can change recipients or rates, that power is part of the product’s trust model. We define who holds it, whether changes are delayed, and how active listings behave afterward.

For an initial release, immutable rates with a carefully controlled recipient-recovery process may be easier to explain than unrestricted edits. There is no universally correct choice, but hidden authority is never a good default.

Make the settlement arithmetic explicit

We specify the calculation before implementing it. For a hypothetical sale priced at 1 ETH, with a 7.5% creator royalty and a 2.5% marketplace fee, both calculated on the gross price, the distribution is:

• Creator: 0.075 ETH.
• Marketplace: 0.025 ETH.
• Seller: 0.9 ETH.

Transaction gas is separate unless the product explicitly subsidizes it. We should not silently include network costs in a fee description that implies something else.

All contract arithmetic uses integer amounts in the currency’s smallest unit. We define rounding behavior and where any remainder goes. With collaborator splits, we ensure the total distribution never exceeds the available balance.

We also avoid ambiguous labels such as “net proceeds.” Does net mean after marketplace fees, after royalties, or after everything? Our listing preview, checkout, contract calculation, and accounting export should answer identically.

For the first version, a small set of supported payment currencies is usually safer than accepting arbitrary tokens with unexpected transfer behavior.

Treat royalty interoperability as work in progress

As of March 2021, EIP-2981 is a draft proposal worth following. It describes a standard way to query royalty information, returning a recipient and royalty amount for a supplied token identifier and sale price.

That interface can help marketplaces discover a royalty policy without implementing a different integration for every collection. It does not itself move funds or force another marketplace to pay. Discovery and enforcement remain different responsibilities.

We would consider supporting the draft where appropriate, while documenting its status and watching for changes. We would not present an emerging interface as settled infrastructure.

Our internal design should also leave room for adapters. Existing collections may expose royalty information through other mechanisms, and some may expose none. We need an explicit policy for each supported case rather than guessing from arbitrary metadata.

Interoperability starts with shared meanings: which price is supplied, which currency denominates the result, and which settlement path actually honors it.

Design listings and payouts together

A royalty rule affects the entire order lifecycle. If a seller signs a listing today and a royalty changes tomorrow, we need to know whether the listing preserves its original economics or uses the updated configuration.

We can bind the relevant terms into the order or require settlement-time values to remain within signed limits. Either approach needs consistent behavior across fixed-price sales and auctions. We reject changed economics rather than silently reducing a seller’s expected proceeds.

Our contracts should settle payment and token delivery atomically: either the required actions succeed together or the transaction reverts.

For payouts, we consider recording withdrawable balances instead of immediately pushing funds to every recipient. This can prevent one failing recipient from blocking a sale, although it introduces withdrawal logic and balances that must be secured and explained.

We never allow an arbitrary buyer to redirect creator funds. Recipient updates require clearly defined authorization, not a convenient request parameter.

Build an indexer, not a second source of truth

The blockchain can establish settlement outcomes, but it is not a convenient storefront database. We still need search, listing views, activity histories, notifications, and operational reporting.

For a Google Cloud-oriented implementation, we might use Cloud Run for APIs and event-processing services, Pub/Sub for asynchronous work, and Cloud SQL for indexed marketplace data. Object storage can support application assets and backups. AWS or Azure can serve equivalent roles when a project’s requirements favor them.

We distinguish application hosting from asset permanence. A cloud-hosted file remains dependent on whoever maintains that account. If we use content-addressed storage such as IPFS, we still need a persistence plan; a content identifier alone does not guarantee ongoing availability.

Our indexer records transaction hashes, block hashes, and log positions. Processing must be idempotent, because retries and duplicate deliveries happen. We also account for chain reorganizations and reconcile derived balances against contract state.

The interface distinguishes pending transactions from confirmed outcomes. We avoid treating a wallet signature or submitted transaction as proof that a creator has been paid.

Operational logs should help us investigate failures without collecting unnecessary personal data or exposing secrets.

Keep privileged access small and test failures

Royalty logic combines money movement, external calls, and permissions. We treat it as security-sensitive even when the percentage calculation looks trivial.

We test reentrancy defenses, authorization checks, rounding, zero-value sales, unsupported currencies, canceled listings, expired signatures, and repeated settlement attempts. Signed orders need replay protection, including appropriate chain and contract context, plus a reliable cancellation mechanism.

We also test assumptions: what happens if a token no longer belongs to the seller, an approval is revoked, or a payout recipient cannot accept an immediate transfer?

Administrative powers should be minimal and visible. We prefer separating deployment, emergency controls, and treasury access. Multisignature approval can reduce reliance on one operator, but it does not replace sound contract design.

Independent contract review belongs in the launch plan. We budget for fixing findings and retesting rather than treating review as a badge added immediately before release.

Make royalty behavior visible in the product

Good royalty infrastructure needs good explanations. Before a seller confirms a listing, we show the expected creator royalty, marketplace fee, and seller proceeds. Before a buyer pays, we distinguish the purchase amount from estimated network costs.

Creator dashboards should distinguish earned, withdrawable, and withdrawn amounts. Those states should correspond to real contract behavior, not optimistic application labels.

We also explain the limitations where people encounter them. A sentence beside the royalty setting can say that payment is enforced for sales through our marketplace and depends on support elsewhere.

For our remote team, shared transaction diagrams and written acceptance criteria help design and engineering stay aligned. We can review the same sale from the seller’s screen through settlement to the creator’s withdrawal, without leaving critical assumptions in a meeting recording.

A short pre-launch checklist

Before shipping, we confirm that we have:

• Defined the royalty base, rounding rules, recipients, and supported currencies.
• Documented which sale routes enforce payment and which do not.
• Made administrative powers and update behavior explicit.
• Bound listing economics to clear settlement rules.
• Tested failed transfers, signature replay, withdrawals, and reconciliation.
• Planned asset persistence, contract review, monitoring, and incident response.
• Matched interface promises to actual contract guarantees.

We do not need an elaborate marketplace to begin. We need a narrow, coherent one whose economics remain understandable under real conditions. At Kordspace, we bring design, software, and Web3 engineering together around that goal. If we can help turn a royalty model into a dependable product, start a project, or explore our related services to see how we can collaborate.