BASKT documentation

Overview

Pons launches thousands of memecoins on Robinhood Chain. Nobody can read that one by one.

BASKT turns a pick into a tradable thing. A curator chooses between 2 and 10 listed tokens, memes or tokenized stocks or both, sets the weight of each, and deploys a baskt. From that moment the baskt is an ERC-20 that anyone can buy with ETH in one transaction. Buying mints shares and the protocol buys the underlying tokens behind the scenes. Selling burns shares and returns ETH, or the underlying tokens themselves if that is what you want.

Four properties define it, and they are the reason to read the rest of this page:

• Composition is fixed. Not "rarely changed". There is no function to change it.
• The open door verifies bytecode, not names. A Pons V2 token that graduated lists itself. Pons V1 tokens come from a curated list that governance lists, with the same kind of bytecode check. Base assets, protocol tokens and stocks need a governed door that logs its reason onchain.
• Stocks are listed one by one, in public. Robinhood's registry has no list of assets to ask, so a tokenized stock cannot be verified by a contract the way a meme can. Each one is listed by governance with a written reason recorded on chain, and only if its pool can take about 5,000 USD of trading before its price moves 1%. Memes and stocks can share the same baskt, and Pons also launches memes against stocks.
• Nobody at BASKT can pause exits. Withdrawing your underlying tokens works with the price oracle dead and the protocol paused.

How a baskt works

1. Create

A curator picks 2 to 10 listed assets, gives each a weight between 1% and 50%, names it, and sets a creator fee. Creating costs a flat 0.0009 ETH and requires an initial deposit of at least 0.004 ETH, which goes into the baskt. The curator does not need to hold any of the underlying tokens: the deposit is ETH and the protocol buys the tokens with it.

2. Buy

Anyone sends ETH. The protocol takes the fees (in WETH), splits the rest in proportion to what the baskt already holds, by value, buys each token, and mints shares. The number of shares is derived from what actually entered the vault, not from a quote.

3. Hold

The baskt holds the tokens. Nothing rebalances them. Whatever the market does to the constituents is what happens to the baskt.

4. Sell

Burn shares and choose: take the underlying tokens, or have the protocol sell them and send you ETH.

What can go in a baskt

Memes launched on Pons, Robinhood's tokenized stocks, protocol tokens such as INDEX, and the chain's base assets. Memes are the class that verifies itself, and the check is on the bytecode. A Pons token has no code of its own: it is OpenZeppelin's ERC-20 with no blacklist, no pause and no deployer privileges. BASKT stores the codehash of that contract, with the few bytes that change from one launch to the next masked out, and refuses anything that does not match, so the whole class of "hostile constituent" does not exist among the memes of a baskt. The other assets on the list are the chain's base assets, WETH and USDG, protocol tokens such as INDEX, and Robinhood's tokenized stocks. None of those came from a launchpad, so none of them can be verified this way and all of them are listed by governance, in public, one at a time. USDG is a stablecoin whose issuer keeps its own admin powers, and a tokenized stock is issued by Robinhood, who can pause or block it on their side.

Pons has two generations and BASKT supports both. They are not the same thing:

The asymmetry is not a preference, it is a consequence. On V2 a token has no pool until it graduates, so "has a pool" proves "has graduated" and the protocol can let anyone list without deciding anything. On V1 the pool exists from the first block, so that proof does not exist and no liquidity threshold replaces it: measured on all 10,441 graduated V1 tokens, the ones that graduated and the ones that did not overlap. So V1 enters through a reviewed list instead, and the list is public.

Fixed composition

A baskt never rebalances. There is no keeper, no schedule, no governance switch. The weights a curator declares at creation decide how the first deposit is split, how harvested payouts are split between the tokens, and how much of an unharvested payout a per-token rescue can take, and nothing else. After that, new money is split in proportion to what the baskt holds, so buying never changes what existing holders own. When a token's route cannot be bought in a harvest, its share of that payout stays in the baskt and the next harvest splits it again by weight, so over several harvests it ends up in the other tokens.

This is a decision, not a missing feature. In a basket of memecoins, rebalancing sells the winner while it is going up and buys more of the one going down. A baskt is allowed to drift: if one token does 10x and the others go to zero, the baskt becomes that token, and the holders get exactly that.

There is also no emergency removal. If a constituent goes to zero it stays in, worth zero, and everyone can still exit with whatever the rest is worth. Removing it would mean someone deciding, for everyone, when a memecoin is dead.

Pricing and NAV

The value of a baskt is the value of what is inside it: reserve times price, summed, divided by shares. Prices come from the same Uniswap pool the protocol trades against, read at spot. Each asset has exactly one price source: a stock that has both a v3 and a v4 pool is priced from the one the router uses. ETH's dollar price comes from a Uniswap v3 WETH/USDG pool whose fee tier is fixed at deployment from the real depth measured in the days before, not from whatever looks deepest in that block; it is the same pool the router crosses when a trade needs it.

Spot is instant and manipulable within a block. That is an accepted trade, and the reason it is acceptable is narrow and worth stating: after the seed, no price decides how many shares anyone gets. Deposits and withdrawals in the vault are proportional to reserves and never consult a price. What the price feeds is display, ranking, the router's slippage check, how the router splits a buyer's ETH between legs, the first share of a baskt (1 share = 1 USD of the seed), and the floor a harvest must clear (80% of oracle value). The router checks what was actually delivered, not what a quote promised.

Fees

Two fees, added, never subtracted from each other. The protocol takes its own and the curator takes theirs on top. Nobody's cut comes out of anybody else's.

Two details that matter more than the numbers:

• The curator's fee is fixed at creation and cannot be raised. Not by the curator, not by governance.
• Through the router, fees are WETH. Buying or selling with ETH takes the fees from the wrapped ETH on the way in and on the way out, before it becomes memecoins. Through the vault directly (contribute and withdraw), fees are taken in shares of the baskt, minted to the curator and to the treasury.

The initial deposit at creation pays only the protocol fee, not the curator's own.

Pool fees are separate. Every buy and sell swaps through each constituent's own pool, which charges its own fee. For Pons memes that is Pons' fee plus a creator tax chosen at launch, up to 10% (11% in total at most under Pons' current settings), paid to Pons and to the token's creator, not to BASKT. BASKT's 11% cap covers BASKT's fees only.

Exits

Two ways out:

• Redeem to ETH. The protocol sells your share of each token and sends ETH. Needs the pools to be working and the protocol not to be paused.
• Withdraw the underlying. You receive your proportional share of every token, in kind. ETH held by a baskt is WETH, wrapped one to one, and comes out as WETH.

The second one is the guarantee. It is proportional arithmetic on reserves: it does not read a price, does not call a DEX, and is not blocked by the pause. If the oracle is dead, the pools are dry and the protocol is paused, that function still works. It is tested that way on purpose. A token that cannot be transferred is skipped and set aside in your name; reclamar(token) pays it out later if the token moves again, only to you. If an issuer burns tokens the vault holds, that token's reserve drops to what is really there (ReservaAjustada) and every holder bears the loss in proportion, whatever the order of exit.

Listing an asset

For Pons V2, listing is open. Anyone can add a graduated Pons token to the catalogue, without holding it and without asking: one transaction to set its pool and one to list it, and the create page does both for you. The protocol checks three things and none of them is an opinion:

1. the token's code matches the reviewed Pons token contract: same length and same hash, with only the values set at its deployment masked;
2. the Pons factory recognises it;
3. its canonical pool exists and holds real liquidity at the moment the oracle is set.

Nobody chooses which pool prices a token. It is derived from Pons's own registry. That is deliberate: letting the lister pick the pool was a real hole, found in review, that let an attacker point the oracle at a pool they owned.

For Pons V1 the door is governance only, for the reason in What can go in a baskt, and the pool must hold at least 1 WETH.

Protocol tokens such as INDEX are governance only too, through listCanonicalAsset as the crypto class, each priced from one declared pool. Their bar sits between the two: the pool has to absorb about 400 USD of trading on its thinner side before its price moves 1%, which keeps a 200 USD leg under half a percent of impact, and a token whose pools do not clear it is not listed until they do. Large tokens from other chains, if they come, are held to the stock bar below. Pools with a dynamic fee or a hook that acts on swaps are refused by the contract, for every class except the Pons pools that memes graduate into. What they pay their holders reaches the baskt and is harvested like any other payment once the protocol can price it; until then it waits in the vault.

Tokenized stocks are governance only too, one at a time, with a written reason emitted on chain. The bar is depth that can be used: the pool has to absorb about 5,000 USD of trading before its price moves 1%, measured by walking the liquidity around the current price, and, for stocks priced from a Uniswap v3 pool, the contract refuses a pool holding less than 10,000 USDG or the same value in ETH. On either route the listing also needs at least 100 USDG tradable around the current price (0.001 WETH for a stock quoted in ETH), checked by the contract when the pool is set. In a full rehearsal against a copy of mainnet on 4 Oct 2026, with the bar then at 10,000 USD, 31 stocks passed. The check runs once, at listing; after that the pools are watched off chain, and moving a stock to another pool is a timelocked governance decision.

Every listing whose bytecode is not checked runs a transfer test first: the lister sends a small amount, the registry passes it on to a burn address, and the token is refused if less arrives than was sent. Pons tokens skip the test because their code is checked against the reviewed contract and has no transfer fee. Tokens that charge a fee on transfer are not supported.

Curators

A curator is whoever deployed a baskt. They set a name, a ticker and a fee, and they earn that fee in WETH on every buy and every sell of their baskt, forever, without touching anything again.

They cannot change the composition, cannot raise the fee, and cannot stop anyone from exiting. After creation they can edit their profile in the app, set their baskt's metadata URI through the contract (the app does not show it yet), and lower its deposit cap, which stops new buys but never exits.

$BSKT

The protocol token launches on Pons like any other token: no presale, no VC round, no team allocation, no vesting schedule for insiders. 10% of the supply is set aside for the Genesis community, the people who took part in the campaign before launch. With no team tokens to take it from, it is bought at the launch as the launcher's initial buy on the Pons curve (the dev buy), and the wallet that holds it is published the same day. It is distributed under rules published before the distribution. The 10% is the size of the pool, not a promise of an amount to any wallet; see the campaign terms.

Revenue goes to buyback and burn in two phases. Before $BSKT exists there is nothing to buy, so fees go to a 2 of 3 multisig treasury, which funds the token launch and the purchase of the Genesis 10%; whatever fees do not cover, we pay ourselves. From the $BSKT launch, the treasury becomes a contract that splits the fees collected in ETH and WETH 80% to buying $BSKT and burning it and 20% to operations. Anything else that reaches the treasury (baskt shares from direct vault use, recovered tokens, dust) goes to operations. Governance can change the split, but a floor in the code keeps the buyback share at 20% or more. The split and the buyback are permissionless: anyone can call them. Since that part of the revenue is already ETH or WETH, there is nothing to sell before buying.

Risk disclosures

• Baskets hold volatile tokens, memecoins included. A baskt can go to zero. Several of its constituents probably will.
• No rebalancing means no protection. A baskt that concentrates into one token stays that way.
• Tickers repeat. Pons does not reserve names. Two tokens can share a symbol. Check the address.
• Thin pools move. Entering or exiting a baskt with shallow constituents moves their price against you. The app warns when a pool is thin; it does not stop you.
• Curators can be anonymous. A curator is a wallet address: its stake and every basket it launched are public onchain, but who is behind it may not be. Past performance is not a promise.
• The swap route can be replaced. Governance can replace the router's swap route after the 48 hour timelock, with no onchain limit on what it delivers. The app values every trade before you sign and refuses one that is worth much less than it costs; withdrawing the underlying never uses the route.
• Payouts wait for a harvest. Payouts that reach a baskt count in the share price only once a protocol harvester wallet harvests them, and whoever enters right before a harvest takes part of them.
• The code is reviewed, not audited by a third party yet. See Reviews.

Network

Contracts

Published here on deployment day, with the block each one was deployed in so anyone can verify them from the explorer.

Creating a baskt

One transaction: it deploys the baskt, takes the creation fee, buys the constituents with the ETH you send, and mints your shares. createAndSeed takes a single struct, CreateAndSeedParams, with the baskt's parameters nested inside it as index.

// constituents MUST be sorted ascending by address, and weights must sum to 10000
await walletClient.writeContract({
  address: INDEX_ROUTER,
  abi: routerAbi,
  functionName: "createAndSeed",
  args: [{
    index: {
      name: "Top 5 Memes",
      symbol: "bMEME5",
      metadataURI: "ipfs://...",
      quoteAsset: WETH,
      constituents: [tokenA, tokenB, tokenC],
      weightsBps: [4000, 3000, 3000],
      creatorEntryFeeBps: 300,    // 3%, fixed forever
      creatorExitFeeBps: 300,
      implementationVersion: 1,
    },
    minAmountsOut,                // one per constituent, none of them zero
    maxSlippageBps,               // at most 1000 (10%)
    deadline,
  }],
  value: creationFee + deposit,   // deposit >= 0.004 ETH
});

minAmountsOut is one minimum per constituent and none of them can be zero. maxSlippageBps is how much value the whole purchase may lose, and the router refuses anything above 1000 (10%). The initial shares are not a parameter: the router derives them at 1 share = 1 USD of what was deposited. Derive them from a simulation, not from a fixed percentage: pool fees and price impact differ per token and a flat 1% will revert against real Pons pools.

Buying and selling

// buy with ETH
await walletClient.writeContract({
  address: INDEX_ROUTER, abi: routerAbi, functionName: "mintWithETH",
  args: [{ indexId, quoteIn: 0n, minSharesOut, minAmountsOut, deadline, receiver }],
  value: amountInWei,
});

// sell for ETH
await walletClient.writeContract({
  address: INDEX_ROUTER, abi: routerAbi, functionName: "redeemToETH",
  args: [{ indexId, shares, minQuoteOut, minAmountsOut, deadline, receiver }],
});

// or take the tokens themselves, straight from the vault
await walletClient.writeContract({
  address: vault, abi: vaultAbi, functionName: "withdraw",
  args: [shares, receiver, minAmounts],
});

Approve the baskt's ERC-20 to the router before selling. The underlying path needs no approval to anything but the vault itself.

Getting a quote

Quotes are not view functions, and that is not an oversight. The only exact way to know what a basket trade returns is to execute it, so the router runs the whole operation, legs in the same order as the real one, and reverts with the result. Call it with eth_call, from the account that will sign.

const data = encodeFunctionData({
  abi: routerAbi, functionName: "ejecutarSimulacionDeCompra", args: [indexId],
});
const { data: raw } = await publicClient.call({
  account: user, to: INDEX_ROUTER, value: amountInWei,
  data: encodeFunctionData({ abi: routerAbi, functionName: "simular", args: [data] }),
});
// `simular` returns the SimulacionDeCompra error data: decode it with the router ABI
const ret = decodeFunctionResult({ abi: routerAbi, functionName: "simular", data: raw });
const { args } = decodeErrorResult({ abi: routerAbi, data: ret });
const [net, allocation, received, shares] = args;

received is what each constituent delivers and shares what you get, to the wei at the current block: build minAmountsOut and minSharesOut from them with your tolerance on top. Selling is ejecutarSimulacionDeVenta(indexId, shares, owner), which needs the router approved for the index token first; seeding a new basket is ejecutarSimulacionDeSiembra(params), with the creation fee plus the deposit as value. Any other error (no route, paused, a leg with no liquidity) comes back as it is.

The older previewMint and previewRedeem are still there to show a number without a wallet, but they quote each leg against the state before the trade. When two constituents trade through the same pool (the WETH/USDG root, or a meme quoted against another meme), the second leg executes against a price the first already moved, so minimums built from them can revert. Use the simulation for anything you sign.

Reading state

// what is inside, and how much of each
const [tokens, reserves] = await publicClient.readContract({
  address: vault, abi: vaultAbi, functionName: "getComposition",
});

// value per share, in USD with 18 decimals (navUsd is the whole baskt)
const nav = await publicClient.readContract({
  address: vault, abi: vaultAbi, functionName: "navPerShare",
});

// is this token listed, and which oracle prices it
const info = await publicClient.readContract({
  address: ASSET_REGISTRY, abi: assetsAbi, functionName: "assetInfo", args: [token],
});

Declared weights and real weights are different numbers and the app shows both. The declared weight is what the curator asked for at creation. The real weight is what is in the vault today, after the market moved.

Two more reads that save a failed transaction. remainingCapShares() on the vault is how many shares can still be minted before the deposit cap; a buy above it reverts with DepositCapExceeded. valeDe(holder, token) is what a holder can still claim with reclamar(token). And one field not to rely on: the class_ that IndexRegistry stores for a baskt is the class of its first constituent by address, so it does not describe a baskt that mixes memes and stocks.

Events to index

Everything needed to rebuild the protocol's state without our infrastructure, plus one getComposition read at the block of each Seeded and of each Cosechado: neither carries the amount that reached each token.

AssetListedVia, ProvenanceWaived and RentaRescatada exist so that any decision governance makes by hand is visible in the log, not only in the result.

Errors

Reviews

Fourteen review passes, all closed. An external audit has not been done. We say it that way on purpose: calling this "audited" would mean something we have not paid for.

What the passes were and what they cost: six internal reviews and eight AI-assisted passes, from 8 Sep to 20 Oct; the first AI-assisted pass found 35 issues and the second reopened a critical one. The last one, before mainnet, read the whole system again in ten phases: 566 issues in its first nine, none critical or high, and nothing that reaches a basket's reserves or blocks withdrawing in kind. Every one was fixed or accepted in writing, and the tenth phase checked each fix against its proof of concept. Most findings have a regression test that fails if the bug comes back. The most serious ones were the same shape twice: an attacker choosing which pool priced a token, which let them drain 95% from someone buying through the official route. Both are closed, and the fix was structural, not a patch: the pool is now derived from Pons's registry and cannot be supplied by a caller. A later pass found that open harvesting could be sandwiched by whoever harvested, invisibly to any check in the contract, so harvesting moved to wallets governance authorizes, which quote every swap outside the transaction. The test suite has over 1,500 contract tests plus 46 that run against a copy of mainnet, and the deployment scripts have been rehearsed end to end on a local copy of the chain.

An external audit is on the roadmap and will be linked here when it exists.

What the protocol cannot do

The short list of things that are impossible by construction, not by policy:

• Nobody can change a baskt's composition. There is no function.
• Nobody can raise a curator's fee after launch. Not the curator, not governance.
• Nobody at BASKT can stop you withdrawing your underlying tokens. Not the pause, not a dead oracle, not an empty pool. The chain's operator can refuse transactions that involve an address it restricts, withdrawals included: see the risk disclosure.
• Nobody can list a token through the open door unless its bytecode matches. The check is in the listing path. The two governed doors are the only other ways in, governor only: listAssetVia runs a validator governance approved (the Pons V1 check), and listCanonicalAsset skips provenance but requires a written reason, emitted onchain as ProvenanceWaived.
• Nobody who lists a token chooses how it is priced. The oracle is derived, not supplied.

What governance can do, always through a 48 hour public timelock: change fee parameters within their caps, turn on the harvest fee (at most 1%), list Pons V1 tokens, base assets, protocol tokens and tokenized stocks, turn on stocks in baskts, name the wallets that harvest fees, replace the router and the swap and price adapters, set how a pair asset is priced, approve new vault versions, raise a baskt's deposit cap, deprecate a baskt, unpause, and announce that it will move unharvested fees to the treasury, then move them in the 7 days after a 30-day notice if nobody harvested in between (for an announcement of one token's share, if no harvest bought that token), never more than there was at the announcement. A 2 of 3 multisig proposes to the timelock and, 48 hours later, executes. The same multisig acts at once only on labels in the baskt registry (curated, risk flags) and to name the guardian, and it can hand that admin power to another account at once, which nothing, not even the timelock, can then take back. The guardian, a separate multisig, can pause and can take away at once a bot wallet's right to harvest and to sample pair-asset pools (it can never grant them), from the moment the team knows: the harvest bot reports, on its next hourly run, every harvest it did not sign itself; pausing never blocks withdrawals or harvests.

Support

Integration questions: contact@onchainbaskt.com, or Telegram.

BASKT is built on Robinhood Chain, on top of Pons. It is not affiliated with Pons, Uniswap or Robinhood. Figures on this page carry the date they were measured onchain, for a reason: they change. Nothing here is financial advice. See the Terms of Use, the Privacy Policy, the Risk Disclosure and the Genesis campaign terms.