How RobinShare works, in full.

What it does

You name a builder — a GitHub handle, or a wallet address — and a coin launches for them on pons, the launchpad on this chain. From that moment a cut of every trade collects in a contract addressed to that identity. They need no wallet for you to launch it, and no idea that it happened. Later they prove the identity is theirs and withdraw.

Three steps, and only the first one is yours: name them, fees accrue, they claim.

The money

pons charges 1% on every trade and forwards 70% of that to whoever is registered as the coin's creator. RobinShare registers the vault instead of a person, so 0.70% of every trade reaches the builder with nothing else configured.

You can add a creator tax on top at launch, up to the cap pons enforces (reading the cap off the chain…). Traders then see 1 + tax on the coin's pons page and the vault takes 0.70 + tax. The default is zero extra, so the coin looks like any other coin on the launchpad and the builder still earns 0.70%.

In the first seconds after a launch the vault takes more than that, because pons' snipe tax lands in the same bucket.

Launching costs the pons launch fee (reading the fee off the chain…) plus gas. RobinShare charges nothing on top, and takes nothing out of the vault: withdraw() transfers the contract's entire balance to the wallet that proved the identity.

Claiming

GitHub. The builder logs in through the real GitHub OAuth flow. Our service signs a voucher for the wallet they connect, and the contract verifies that signature on chain.

Wallet. If the vault was made for an address, that address signs a message. Nothing else is involved.

There is no third route, and that is enforced on chain rather than by policy: this factory was deployed with its third verifier set to the zero address, so creating a vault of that kind reverts. You can read the argument yourself in the factory's constructor data on the explorer.

Claiming costs the claimer one transaction in gas today. There is a relayer that pays that gas for them; it is written and tested, and it is currently switched off. On the first real claim, gas came to 36% of what was collected — which is small only because the amount was.

The vault

One vault, one identity, fixed at launch. No owner, no upgrade path, no pause and no emergency hatch. Nobody can drain it, and nobody can fix it either if it turns out to be wrong.

The recovery window is the exception, and it is the thing to check. Whoever launches can arm one: a number of days, minimum thirty, off unless they turn it on. Once that window passes, they can pull out whatever nobody has claimed — and keep pulling as more fees arrive — for as long as the identity stays unproven. Aimed at a handle nobody can claim, that is not a safety valve, it is a guaranteed clawback.

The number is written into the vault when it is created and cannot be changed afterwards. Every claim page reads it back off the chain and shows it as a badge, so you can always tell an irrevocable vault from one with a window on it before you trust the coin.

Powers that are not ours to disclaim

Two of these are on every page of this site. The third is a gap rather than a key.

pons. The launchpad's owner is a 2-of-3 multisig that can point any coin's creator fees somewhere other than the vault, behind a public three-day timelock. It applies backwards to anything still sitting in the launchpad rather than swept into the vault, so sweeping early is the whole mitigation.

Our attester key. On a GitHub vault, our signature is the proof of identity, so that key can bind any GitHub vault to any wallet. That is inherent to attesting an OAuth login on a blockchain. A second key on a cold wallet exists to replace the attester if it is ever lost, and it can also rotate the attester to itself and then sign — so it is two keys, not one. Vaults made for a wallet address depend on neither.

Graduation. If a coin crosses the bonding curve and graduates, the vault has no route of its own to the pool's fees; from there it depends on the pons operator. Roughly one launch in a hundred gets that far. It is the success case, and it is the case this rail covers worst.

Limits

ETH-paired launches only. With an ERC-20 pair, pons credits the fees into a per-token ledger the vault cannot pay out from, so attachToken() refuses those launches outright instead of trapping the money. That rules out roughly half of pons.

No takedown. Anyone can already put anyone's name on a coin, on any launchpad, and nothing here changes that. What changes is where the money goes. If a coin exists with your handle on it and you would rather it did not, RobinShare cannot delete it. The vault is addressed to you, you can ignore it forever, nothing binds you to the coin and the coin does not speak for you.

These are memecoins on a bonding curve. They can go to zero, and most do. Nothing on this site is investment advice.

No audit

This contract has not been audited. That is a decision, not a pending task, and there is no audit booked.

What it has instead: 56 unit tests on this rail, 10 fork tests that run the whole money cycle against pons' deployed contracts, and two rounds of adversarial review. The factory is verified on the explorer with an exact bytecode match, which proves the code you can read is the code that is running — and nothing about whether that code is right.

An external audit does exist, and it is not of this. It covers the earlier version of the product, on a different launchpad — a tree whose entrypoint, harvest path and payout were all rewritten to get here. None of it carries over.

Addresses, and how to check any of this

Chain

Robinhood Chain · 4663

Factory

0xBf25E1d9082B5Ad0b8C68f072E94C797028c6855

pons launch factory

0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e

Source

github.com/robinshareapp/robinshare

Any vault publishes what it owes and what it already paid. Open one on the explorer and call pendingAmount() and totalPaid(): those two numbers are the whole product, and they do not come from this page.

The promise, verbatim