Metadata and Token Setup: The Fields a Stranger Reads

Token metadata is the short set of fields a stranger reads before deciding whether to look further: name, ticker, image, description and links. On Solana the mint account carries supply and decimals, while those readable fields live in a separate metadata account that normally points at a JSON document and an image hosted elsewhere. Assembling them is preparation work, and it should be finished before mint.

This page covers how those fields are produced, how they are read, and how hard each one is to change once a token exists. It belongs to the preparation phase of the handbook and sits next to the sign-off sheet rather than replacing it. It will not tell you what to name your token. It tells you what each field is doing and what it costs to get wrong.

MINT ACCOUNT

Holds supply and decimals. SOL itself uses nine decimals; a token sets its own at creation.

METADATA

A separate account, not the mint, holding name, symbol and a pointer to a JSON document.

IMAGE

Almost never on chain. The JSON document points at a file on external storage.

EDIT RIGHTS

Depend on the launchpad and on how the metadata was created. Verify before mint, assume permanence.

What metadata actually is on Solana

A Solana token starts as a mint account. That account is identified by a base58 address, and it records the technical facts of the asset: how many units exist, how many decimal places a unit divides into, and which authorities, if any, can still mint or freeze. None of that is readable to a person. A mint address on its own is a string of characters with no name attached.

The readable layer is added separately. A metadata account is derived from the mint address and stores a small number of fields, most importantly a name, a symbol and a uniform resource identifier. That identifier normally points at a JSON document held on ordinary web storage, and the JSON document in turn names the image file, the description and the links. The chain stores the pointer, not the picture.

This two step arrangement is why token metadata behaves the way it does in practice. The on chain part is small, cheap and durable. The off chain part is a file on a host, which means it can be served slowly, cached aggressively by wallets and explorers, moved, or one day not served at all. Both halves have to be right for a token to look finished.

Launchpads hide all of this behind a form. When you fill in a create screen on a bonding curve platform, the platform is assembling the same components: it uploads your image, writes a JSON document, creates the mint, creates the metadata account and points one at the other. The convenience is real. The consequence is that you inherit whatever storage and authority decisions the platform made, and you should know what those are before you sign.

The practical reading of all this is simple. Treat the mint as the permanent object, treat the on chain fields as very hard to change, and treat the off chain document as changeable only if you or your platform still control where it is served from. The technical background of accounts and mints is documented publicly by the Solana project if you want the primitives rather than the summary.

The fields the launchpad form asks for

Most create screens ask for the same handful of inputs, in roughly the same order: name, ticker, image, description, and a set of optional links for a website and social channels. Some add a banner, a category or a first purchase amount. The form is short enough that teams fill it in the last five minutes, which is exactly the wrong time to write the only sentence a stranger will read.

Every one of those inputs does a different job. The name is what appears in prose and in search. The ticker is what appears in a price row and in chat. The image is what appears next to both, usually far smaller than you designed it. The description is the only field where you choose your own first sentence. The links are the field where you are tested, because a visitor clicks them to see whether anyone is home.

Before you open the form, have every field written and approved in a document. Copy and paste them in. Filling a mint form live, with a person reading suggestions over your shoulder, is how tokens end up with a stray capital letter in the ticker and a description that ends mid sentence. The pre-launch sign-off sheet exists so that this material is finished a day early.

• Name, written exactly as it will appear, with capitalisation decided.
• Ticker, in the case you intend, checked against existing tokens.
• Image, exported square, checked at thumbnail size and at full size.
• Description, one or two sentences, written to be read cold.
• Links, each one opened from a device that is not signed in.
• A record of who approved each field, so nobody edits it at the desk.

Keep the approved text in a plain file rather than a chat message. Chat messages get edited, quoted and misread; a file with a filename gets pasted. It also gives you a record when someone asks two weeks later why the description says what it says, which is a question that always arrives eventually.

Field by field: purpose, reading, permanence

The table below is the working summary this desk uses when reviewing a setup. The third column is the one people skip: it is not what the field means to you, it is what a stranger infers from it in the second or two they spend. The fourth column deliberately avoids promising anything, because editability is a property of your launchpad and your authorities, not of the field name.

Two entries in that table deserve a second look. The creator wallet is metadata whether you intended it or not, because the address that signed your mint carries every earlier transaction it ever made, and a curious visitor can open it on a public Solana explorer without asking you anything. Decide which wallet signs before launch day, not during it.

The other is the image. Teams treat it as the easy field because a designer already made one, and because it is the only field that arrives looking finished. In practice it has the least forgiving display conditions of anything on the card, the most external dependencies, and the shortest window in which it is judged, so it is worth a section of its own.

Name and ticker: collisions and confusion

Nothing prevents two tokens from sharing a name or a ticker. On a permissionless launchpad the same three or four letters can be minted by anyone, repeatedly, on the same afternoon. That is not a bug you can report; it is the operating condition. Your job is to choose a pair that survives it, and then to publish the mint address in every place a person might look for you.

Collision hurts in two directions. Someone searching for you finds a different token and buys it, which costs you a holder and costs them money. Or someone searching for a token they saw elsewhere finds you, arrives confused, and leaves annoyed. Both look identical from the outside: a visitor who bounces. Neither is fixable after the fact, which is why the check happens before the form.

Run the search yourself, on the launchpad and on the aggregators people actually use, before the name is agreed. Search the exact ticker, the name as one word, and the name with a space. Look at what already carries those characters and how prominent it is. A ticker that returns nothing today may still return three things next week, so also ask whether your name is distinctive enough to be searched with a second word.

Case matters more than teams expect. A ticker written in mixed case in your own materials and in capitals everywhere else looks like two different projects to a casual reader. Pick one form, write it into the approved text file, and use it in every post. The same discipline applies to spacing and to any punctuation in the name, which some interfaces will strip and others will keep.

The image, and what survives at 32 pixels

The image is judged before the name. In a feed of tokens it is the only element rendered at full strength, and it is usually rendered very small. Whatever you design, assume the version most people see is a thumbnail beside a row of numbers, and that it will sometimes be cropped to a circle. Detail that only reads at full size is decoration you paid for and nobody sees.

Here is the arithmetic, purely as an illustration. Take a source image exported at one thousand pixels square and displayed as a thirty-two pixel avatar. That is a reduction of about thirty-one to one across, so a stroke five pixels wide in your original arrives as roughly one sixth of a pixel: it does not thin, it disappears into whatever colour surrounds it. A shape that needs to survive must be at least a few dozen source pixels wide.

The same reduction explains why text in a token image almost never works. A word set at sixty pixels in a one thousand pixel canvas becomes under two pixels tall in the thumbnail. It becomes a grey bar. If your image contains your ticker as text, test it at the small size and decide whether the grey bar is what you want under the name that already says the ticker.

Check three things before you accept an export: the thumbnail, the circular crop, and the image on both a light and a dark interface. Wallets and explorers do not agree on background colour, and an image with a white background that was designed on a white canvas will appear as a bright square on a dark list. That is not fatal, but it should be a decision rather than an accident.

File format and weight matter less than people fear and more than nothing. A very large file will still load, but it will load late on a slow connection, which means the first impression is an empty circle. Export at a size that is sharp when opened full screen and no larger, and confirm the file is served over a link that will still resolve in six months.

The description and the links

The description is the only field where you choose the first sentence a reader sees. Everything else in the interface is a number someone else generated. Spend it saying what the thing is, in language a person outside your group would use. If a friend who does not follow launches read it aloud, they should be able to say what the token is for without asking a follow up question.

Write it flat. Adjectives read as noise in a list where every other entry also claims to be the next big thing, and a reader has trained themselves to skip them. Two plain sentences beat one dramatic one. Avoid promising anything about price or outcome, both because it is not true and because it is the fastest way to be filed alongside every project the reader has already decided to ignore.

Links are a different kind of field, because they are tested rather than read. A visitor clicks, waits, and forms a conclusion about your project from what loads. That conclusion is about your team, not about your website. This is why a dead link is worse than no link at all: an empty field says nothing yet, while a broken one says something was here and is not any more.

Open every link from a device that is not signed in to any of your accounts. A private channel that looks fine to an administrator can be an error page to everyone else. Invite links expire. Handles get changed and the old one silently belongs to somebody else. A domain you registered but never pointed anywhere serves a parking page covered in advertisements, under your token's name.

Publish only channels you will keep answered. A visitor who joins a chat and sees the last message was posted before the launch draws the obvious conclusion, and there is no way to explain it afterwards. Fewer live surfaces is a stronger position than a complete looking row of icons where most of them lead somewhere silent.

What is permanent, and what only looks editable

Be careful about what you have been told here, including by this page. Whether a specific field can be edited after mint depends on the launchpad you used and on how the metadata was created: whether an update authority still exists, who holds it, and whether the platform exposes any edit path at all. Some platforms let you change nothing. Verify on the platform itself rather than assuming.

The safe operating rule is to treat everything as permanent, then be pleasantly surprised. That rule costs you one careful hour before mint and saves you the situation where a typo in a ticker becomes the permanent identity of a project. It also stops the more expensive failure, which is a team that ships something half finished because they believe they can fix it later.

There is a second layer of permanence that no authority controls: distribution. Even where a field can technically be updated, the old value has already been copied into caches, screenshots, aggregator databases, chat previews and other people's posts. Changing the source does not recall the copies. In practice a token that changes its name after launch spends months being two tokens in the public record.

The creator wallet is the clearest case. It cannot be edited under any circumstances, because it is a signature in a ledger. If that address has a history you would rather not discuss, the decision to be made is which wallet signs, and it has to be made before the mint. This is one of the recurring items in the mistakes that repeat from launch to launch.

How a stranger reads the card in three seconds

Visitors do not read metadata in the order you filled it in. They scan in a rough sequence, dropping out at any point, and most of them drop out. Knowing the order tells you where to spend effort. The table below is a working model of that sequence rather than a measurement, and it is written as elapsed time because that is how it feels from the other side of the screen.

Two conclusions follow. First, the image and the first line of the description carry a share of the work far out of proportion to the time teams spend on them. Second, everything after three seconds is about presence rather than presentation, which means it is decided by how you behave on the day rather than by anything in the form. That behaviour is the subject of the launch day timeline.

It also explains why polishing a long document before fixing a thumbnail is the wrong order of work. Almost nobody reaches the document, and the people who do have already decided to take the token seriously by the time they open it. Nearly everybody sees the small round picture and the one line beside it, and most of them see nothing else. Spend the effort where the traffic is.

The review procedure and the stack around it

Run the following sequence with two people, at least a day before mint, with the form closed. Doing it in front of the create screen turns a review into an argument about whether to ship, and the review always loses that argument. Write the outcome into the approved text file and treat the file as the single source for every field.

1. Search the exact ticker and the name on the launchpad and on the aggregators you expect to appear on. Record what already exists.
2. Say the name out loud and spell it for the other person. If it needs spelling twice, it will need spelling forever.
3. Open the image at thumbnail size, as a circular crop, and on both light and dark backgrounds.
4. Read the description cold to somebody outside the project and ask what it is and who it is for.
5. Open every link on a device signed out of all your accounts, including the website if you have one.
6. Decide which wallet signs the mint and open its history on an explorer as a stranger would.
7. Check on the platform itself which fields it allows you to edit after mint, and write down the answer with the date you checked.
8. Freeze the file. Any change after this point needs the same two people, not one person at a keyboard.

Alongside the fields, preparation owns the operational stack you will actually run on the day: which explorer tabs are open, which chat surfaces are staffed, which dashboard the watcher is reading, and whether any automated market activity such as a Solana trading volume bot is part of the plan. That last category routes trades and produces recorded activity; it changes nothing about your metadata and nothing about your audience.

The reason to settle the stack now is that every one of those choices has a setup cost, and setup costs on launch day are paid out of attention you do not have. Accounts need funding, tools need configuring, dashboards need bookmarking, and every one of them fails the first time you use it. Discover that on a Tuesday, not while the curve is live.

Be plain with yourself about what any of it does. Recorded activity is a record of transactions, not evidence of demand, and no configuration changes the fact that who buys and when attention arrives are outside your control. Whether a curve completes is not something you decide. The purpose of good metadata and a rehearsed stack is narrower and more honest: when somebody does look, nothing in the first ten seconds gives them a reason to leave.

Everything on this page belongs to the phase before the mint transaction, which is where the whole four phase operating plan puts it. Once the mint is signed, the fields are what they are, and the work moves to being present, answering questions and reading the curve honestly. Preparation is the only part of a launch that is entirely yours.

Questions the desk is asked