Creators, verification and the KYC gates

/admin/nft/creator is the roster of everyone who has a creator profile on your marketplace. Verifying at least one of them is a launch requirement — the onboarding checklist will not pass without it — and verification is a manual decision with no evidence attached to it, so it is worth understanding exactly what you are publishing when you make it.

There is no "add creator"

Profiles are created automatically, by eight different code paths, the first time a user touches anything creator-shaped:

• creating a collection (POST /api/nft/collection);
• listing their collections (GET /api/nft/collection/list);
• opening the creator dashboard, overview or profile;
• saving their creator profile (PUT /api/nft/creator/profile);
• reporting a mint (POST /api/nft/token/mint-web3);
• anyone viewing GET /api/nft/creator/{id} for a user who has no profile yet.

New rows land unverified, profilePublic true, all totals zero, with a displayName derived from the user's name — or creator_<first 8 characters of the user id> when they have none.

The screen

Opening the page needs access.nft.creator; the table behind it is served by an endpoint gated on view.nft.creator. Create, edit and delete are switched off in the interface, because a creator profile belongs to its owner.

Columns: the linked user (avatar, name, email), display name, an Active toggle, Verified, Tier, NFTs, sales, volume, floor price, public profile, bio and joined date. Opening a row gives a read-only detail dialog with the four lifetime figures.

The one control on the screen is the Active toggle, and it does not do what its name suggests:

nft_creator has no status enum. The toggle maps true to profilePublic: true and false to profilePublic: false. Switching a creator off hides the profile; it does not suspend their collections, cancel their listings or stop them minting. Do those on the Collections, Listings and NFTs screens.

Verification is an API call in this build

The creator table has no edit form — canEdit is off — so there is no button on this screen that sets isVerified or a tier. The endpoint is how it is done:

{
  "id": "<nft_creator.id, not the user id>",
  "verificationTier": "GOLD"
}

Setting any tier flips isVerified to true automatically, so a tiered but unverified creator is not representable. You can set isVerified on its own without a tier; you cannot do the reverse.

The body also accepts displayName and bio, which are written.

Permissions to note: both write routes are gated on plain edit.nft, not on a creator-specific key. Anybody who can edit anything in the NFT addon can verify a creator.

What verification means

Nothing, to the software. No route reads isVerified to grant a capability, no fee changes, no limit lifts. It is a badge on a profile and a filter on a table.

That makes it entirely a trust signal you are publishing on your own marketplace, in your own name, to your own customers. Four tiers with no defined meaning is four ways to be misunderstood, so:

• write down what each tier requires before you award the first one, and put it on your terms or your help pages;
• keep the evidence somewhere outside the platform — nothing on the creator row records who verified them, when, or why;
• remember it is reversible only by another API call, and no notification is sent either way.

The launch checklist wants one

/admin/nft/onboarding — the four-phase checklist, itself not in the navigation — has a User & Creator Management phase whose single task is Verify First Creator. GET /api/nft/onboarding/status marks it complete when at least one nft_creator row has isVerified = true, and not before.

So verifying somebody is part of a clean launch, and it is the only phase of the checklist that cannot be satisfied by configuration alone.

The three KYC keys

All three live on Admin → NFT → System → Settings → Verification. They are not equivalent, and one of them does nothing at all.

nftRequireKycForCreators gates nothing

The only thing in the product that reads this key is GET /api/nft/onboarding/status, which marks configure verification complete once the row exists — whether it is on or off. Flipping it changes nothing about who may become a creator.

The real gate is the shared create_nft KYC feature, set in the core KYC level configuration. When a creator is blocked by it they see one of two 403s, depending on where they stand:

• never verified — "KYC verification is required to create a collection." (or "…to mint an NFT", "…to mint NFTs");
• verified at a level that does not carry the feature — "Your verification level does not include this feature (create a collection). Complete a higher verification level to continue."

nftRequireKycForHighValue gates a trade, not an account

This is the second gate and it works on a different axis. POST /api/nft/listing/{id}/buy converts the sale price to USD, and when the switch is on and the threshold is above zero and the converted price clears it, the buyer must pass the buy_nft gate before the purchase completes — "KYC verification is required to complete this high-value purchase."

Three details that decide whether it is running at all:

• The threshold is USD, converted from the listing currency at request time. A conversion that cannot be resolved leaves the purchase ungated.
• It is applied per trade, so the same customer buys freely below the threshold and is stopped above it, with no account-level state either way.
• The backend's fallback for the switch is off while the settings screen shows it on. On an install that has never saved the Verification tab the gate is not running. Save the tab once so the row exists.

Above the threshold the check falls back to "holds any approved KYC application" while kycFeatureEnforcement is off, so this one does bite on a normal install — unlike create_nft.

Creator-facing routes you may be asked about

These are what your creators see. All require a login and none takes an admin permission. The first two and the profile route create the caller's profile when it is missing; analytics and stats only read it.

The totals on those screens and the totals in your admin table come from the same nft_creator columns, so a creator disputing a figure is disputing the row you are looking at.

Related

• The admin panel — the other fourteen screens.
• Settings — the Verification tab in full, and the six NFT KYC features.
• KYC applications — where a creator's actual verification standing lives.
• Install and enable — the onboarding checklist in context.