Documentation

What is a SOBJECT

Holding one whole token materializes one object. The object is not a second mint, and it is not a picture that can be listed on its own. Transfer the tokens and the pictures are recomputed for the wallets that remain. Sell down to the same balance later and the same pictures return.

Every launch uses the same supply. The mint has 6 decimals, so one whole token is 1,000,000 base units and the full supply is 1,000,000,000 base units: 1,000 tokens. The curve account holds 800 of them. A migration account holds the other 200 until ascension. A wallet balance of 3.42 tokens is three objects. The leftover 420,000 base units do not mint a fourth.

The first market can only be opened by the protocol authority. That mint becomes the main token, SOBJECT. Later launches are permissionless. None of them set a creator fee, and none of them can withdraw the curve's principal. An admin may pause new launches and curve trading. The pause does not rewrite balances, DNA, or past trades.

The site you are reading quotes this math and reads the cluster. It does not invent markets, volume, or a successful graduation.

DNA

DNA is 32 bytes. It is SHA-256 of a fixed preimage. Nothing in the account stores a picture per holder, and the transfer hook does not write DNA. Rendering reads the balance, the collection seed, the mint, and the wallet, then hashes.

DNA = SHA256(
  "SOBJECT_V1"
  || collection_seed   // 32 bytes
  || mint              // 32 bytes
  || wallet            // 32 bytes
  || object_index      // u32, little-endian
)

The prefix is the ten ASCII bytes of SOBJECT_V1. The object index is the zero-based count of whole tokens in that wallet: the first object is index 0, the second is index 1. Little-endian means the least significant byte comes first, so index 1 is the four bytes 01 00 00 00.

The same inputs always produce the same DNA. Sell down and buy back to the same whole-token balance, in the same wallet, and the same objects return. A different wallet holding the same number of the same mint gets different objects, because the wallet is inside the hash. Two objects in one wallet differ because the index is inside the hash.

The collection seed is shared by every holder of that mint. Its first four bytes are the pack style:

Style picks the species. DNA picks the individual: expression, hair on a portrait, where speckles land, and which side a charm sits on. Hair, expression, speckles, and charm side come from mixing the DNA. They are not extra fields in the seed.

Transform, not transfer

Objects do not move. When Alice sends tokens to Bob, Alice's remaining balance redraws her objects and Bob's new balance draws his. If Alice keeps two whole tokens, she still has objects 0 and 1 from her own DNA. Bob's first whole token is his object 0. It is a new hash, with Bob's wallet in the preimage.

Walk a transfer of 2.5 tokens from a wallet that holds 4:

Alice's surviving object is still her index 0. Bob's two objects are his index 0 and index 1. The 0.5 token on each side is dust. Dust changes the balance and does not change the object count.

The Token-2022 transfer hook on the mint is permanent. Mint authority is revoked at launch, and the hook authority is none, with the hook program set to sobject-core. Official Token-2022 updates balances before it calls the hook, so the hook sees the post-transfer amounts. Its job on that path is lightweight: it does not write an object account. Rendering happens off the transfer, from the balance and the seed.

There is no inventory of unique items to trade one by one. The items were never separate assets. Restoring a balance restores the picture.

Packs

There are ten bodies, drawn at 64 by 64 with a one pixel outline and flat color bands. The background of the SVG is transparent. The site shows them on the same black as the mark.

On Create you either take a ready-made pack or generate one. Generate rolls a palette (3 choices), an eye style (round, tall, sleepy), a marking (spots, stripe, freckles, cheek, clean), and a charm (none, horns, glasses, bow, spark). Mech and Knight always draw a visor. Glyph always draws tall eyes. Those locks are part of the body. The eye byte is still written into the seed so the recipe stays explicit.

Stages change the same grid. Dormant closes the eyes and darkens the bands. Awake opens the eyes. Mutated adds the marking and the charm. Ascended adds a ring. Final form adds a crown. An egg stays a closed shell until ascended, then the shell opens onto a face. A portrait's hair comes from the holder DNA, so one collection can hold crops, bobs, long hair, a tuft, or a side sweep. The shirt and the glasses, if you chose them, stay with the collection.

Collection style

Style is not a second renderer id. The on-chain pack id is still a u16, one of the ten bodies, registered before the launch. The recipe lives in the collection seed. Preview on Create shows the shared look, the five evolution stages, and three wallets with the same style and different DNA.

The TypeScript renderer and the Rust renderer consume the same sprite grids. A fixture hash covers all ten packs, all five stages, and two sample seeds. If those hashes diverge, the pictures diverged.

Curve math

The curve is constant product on virtual reserves. Every division floors. The invariant k is the product of the two virtual reserves at launch, and buys keep the product by moving along integer steps of that same k.

A buy takes the SOL the signer sends, peels the fee, then slides the reserves:

fee        = floor(sol_in * bps / 10_000)
net        = sol_in - fee
k          = virtual_sol * virtual_token
new_vs     = virtual_sol + net
new_vt     = floor(k / new_vs)
tokens_out = virtual_token - new_vt

tokens_out is also capped by the real token inventory on the curve. The virtual token reserve starts above 800 tokens so the spot price can rise as inventory leaves. The extra virtual tokens are not spendable. Only the 800 real tokens can be delivered.

Spot price, in lamports per whole token:

spot = floor(virtual_sol * 1_000_000 / virtual_token)

On the fresh curve that is 6,666,666,667 * 1,000,000 / 1,066,666,666 = 6,250,000 lamports, which is 0.00625 SOL per token. The chart below rebuilds virtual SOL as floor(k / virtual token) after each sold amount. That is the integer hyperbola. The dots are the checkpoints in the table.

Worked buy: 1 SOL on a fresh main market

The signer sends 1,000,000,000 lamports. The main fee is 300 basis points.

fee        = floor(1_000_000_000 * 300 / 10_000) = 30_000_000
net        = 970_000_000
new_vs     = 6_666_666_667 + 970_000_000 = 7_636_666_667
new_vt     = floor(k / new_vs)           = 931_179_979
tokens_out = 1_066_666_666 - 931_179_979 = 135_486_687

The buyer receives 135.486687 tokens. Real SOL becomes 0.97. Real token inventory falls by the same 135,486,687 base units. A later token with the same 1 SOL input pays a 10,000,000 lamport fee and receives 137,919,025 base units, because more of the SOL reaches the curve.

The buy that finishes the curve

Net 20 SOL buys the entire 800 token inventory in one shot from a fresh curve. After that trade the virtual token reserve is 266,666,666 and the virtual SOL reserve is 26,666,666,667 lamports. Spot price is 100,000,000 lamports per whole token: 0.1 SOL.

Rebuilding virtual SOL as floor(k / 266,666,666) yields 26,666,666,718 instead. The 51 lamport gap is floor dust. The product of the post-trade reserves sits slightly under k. Both states quote a spot of 0.1 SOL, because the floor division lands on the same lamport price.

The gross amounts that leave exactly 20 SOL after the fee:

Sells

A sell adds the tokens to the virtual token reserve and removes SOL:

new_vt = virtual_token + token_in
new_vs = floor(k / new_vt)
gross  = virtual_sol - new_vs
gross  = min(gross, real_sol)
fee    = floor(gross * bps / 10_000)
net    = gross - fee

The cap matters. Floor division on the way out and the way back can ask for more lamports than the vault holds. The program pays the vault. It does not mint SOL to fill the gap. A sell quote without a live reserve is rejected, because that cap cannot be known from a blank curve.

Migration sizing

The 200 token migration inventory is a separate token account. At the terminal spot, 200 whole tokens would ask for 200,000,000 * 26,666,666,667 / 266,666,666 = 20,000,000,050 lamports: 20 SOL plus 50 lamports. The real reserve only has 20 SOL, so the sizer trims.

tokens = floor(real_sol * virtual_token / virtual_sol) = 199,999,999
sol    = floor(tokens * virtual_sol / virtual_token)     = 19,999,999,950

One base unit of the migration pile stays behind, and 50 lamports of SOL stay in the curve vault. The SOL leg never exceeds the real reserve. This build does not move either pile into a pool. The formula is what a future deposit has to satisfy.

Fees

Fees come out of the SOL leg inside the curve program, and after ascension they are intended to come out in a router in front of the pool. They are not a Token-2022 transfer-fee extension. A transfer of the token itself does not skim a tax. Sending tokens between wallets is free of protocol fee. The fee is on the trade.

The main token, SOBJECT, pays 300 basis points of the SOL leg to the dev wallet stored on the protocol account. That address is configuration, set from the environment and written into the protocol account. It is not a personal key baked into the program binary.

Every later token pays 100 basis points. That SOL is not left as a tip. It is the input of a second buy on the main curve, with fee_bps = 0, and the main tokens from that buy land in a protocol treasury. Because the inner buy uses a zero fee, the 3% is not charged again. The child trade requires the main market to be ACTIVE. If the main market is paused, missing, or already graduating, the child trade stops.

The fee uses floor division, so a small trade can round down to a fee of zero. One lamport on either market pays nothing.

fee + net equals sol_in exactly. Graduation compares real_sol after the net is added, so a buy that crosses the target is sized on the post-fee amount. The table in Curve math is that size: 20,618,556,701 lamports on the main token, 20,202,020,202 on a later token.

Ascension

Graduation uses post-fee real reserves, not the user's gross spend. The production target is 20 SOL. The buy that pushes real_sol to the target completes, the buyer receives the tokens, and then the status flips to GRADUATING. Curve trading stops on that market. The status never moves backwards.

Finalize cannot succeed without a verified pool. The instruction checks the pool and then returns MeteoraDepositUnimplemented. It does not set status to MIGRATED. migrate on the liquidity program checks that the market is GRADUATING and that the DLMM program account is executable, then returns MeteoraPoolNotCreated. It does not move curve SOL or the migration inventory.

A dev-only graduation threshold exists behind the Cargo feature dev-thresholds. That feature is not the default build. The production program rejects any target other than 20 SOL. The dev feature rejects the 20 SOL target, so a dev artifact cannot be initialized as if it were the production target, and a production artifact cannot be initialized with a toy target.

Meteora

The pool venue is Meteora DLMM, program LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo on both mainnet and devnet. This project does not use Meteora Dynamic Bonding Curve. The hook stays on the mint. Disabling the hook, or swapping the venue and calling it done, is not the plan.

A transfer hook that still runs custom logic needs a Meteora TokenBadge. That badge is permissionless only when the hook program and its authority are revoked. Revoking them would make the hook optional, which this protocol does not do. Until a badge and a real deposit are proven, the router refuses a post-ascension swap and does not move reserves while it refuses.

The repository document docs/METEORA_INTEGRATION.md records the same gap. A green test that fakes a pool is not a migration. Final form in the renderer is reserved for a market whose status is actually MIGRATED.

Wallets

Phantom and Solflare connect in the browser. The header control says Select wallet until one is connected, then it shows a shortened address and opens the same modal. The default cluster is devnet. A connected wallet is not a trade.

Buy and sell on a market page quote the live curve. They do not offer a button that pretends a swap was sent. The server does not submit the transaction. Minimums, when a signer builds a transaction locally, are what protect them if the reserves move.

The devnet programs are deployed only after a real airdrop funds the deployer. If the faucet refuses, the site keeps an empty launch list and says so. It does not invent a market to fill the grid.

Errors

Slippage, an empty quote, a paused protocol, a string that is not a mint, or a main market that cannot absorb the child-fee buy all stop the action. The interface prints the failure. It does not replace it with a success toast.

Object index

Object count is the balance divided by 1,000,000, integer division. Index 0 is the first whole token. Index 1 is the second. The index is part of the DNA hash, so object 0 and object 1 in the same wallet are different pictures even though they share the collection style.

A wallet page lists an object only when a real Token-2022 balance covers that index. It does not pad the grid with specimens. Pagination is 12 cards. Fractional dust does not add a card.

Slippage

Buys require a minimum token out. Sells require a minimum SOL out. The program rejects the trade when the quote misses that floor. The quote you see is floor division on the virtual reserves after the fee, so two readers of the same reserves see the same integers.

A quote is not a fill. The market can move between the preview and a signed transaction. If it does, the minimums are what protect the signer. This deployment does not submit that transaction from the server.

On the fresh main curve, the 1 SOL example above is exact: minimum tokens of 135,486,687 fills if nobody trades first, and a higher minimum fails if the reserves have already moved. There is no hidden spread on top of the floor division.

Evolution

Stage follows the share of the 20 SOL target already sitting in the curve as real reserves. The share is basis points, floored:

bps = floor(real_sol * 10_000 / target)

Under 2,000 the stage is Dormant. Under 5,000 it is Awake. Under 8,000 it is Mutated. From 8,000 upward, while the market is not migrated, it is Ascended. Final form is reserved for a migrated market. On a 20 SOL target the cuts fall on 4 SOL, 10 SOL, and 16 SOL, and the boundary itself belongs to the later stage.

A sell that drops the reserve can move the stage back down. The picture follows the curve. It is not a one-way story. The TypeScript renderer and the Rust renderer use the same integer steps.

Reference

Addresses the client is built against. A market exists on a cluster only after these programs are initialized there. An empty launch list means they are not initialized on the cluster this site is reading.