Firstance docs

Trust & verification

Firstance's pitch is that you do not have to trust it. That only means something if you can check it, so this page is about what the programs are actually allowed to do and how you can confirm it for yourself.

What the authority cannot do#

On the Terminal Vault, the authority can set the vault up once, pause it as an emergency stop, and close it, but only when it is already empty. It cannot change the sell rules, move the proceeds address, pull the tokens out, or sell them to itself.

On the Marketing Vault, the authority can rotate the keeper key, propose a distribution round, and sweep leftover dust after all six milestones. It cannot redirect a payout, change an amount, distribute before a milestone, or stop a committed round.

Neither authority can mint new tokens, because there is no open mint authority on the coin at all.

Verified build, open source, and unaudited#

Here is exactly what the security posture is, stated plainly, because overstating it would defeat the point.

  • Open source. Both programs are public on GitHub, under CryptoMehis.
  • Verified build. OtterSec's verified build process confirms that the bytecode running on mainnet matches the public source, so the code you read is the code that runs. This is not the same thing as a security audit.
  • Onchain IDL. The full interface of each program is published onchain, so every keeper action shows up on Solscan with a readable name instead of an opaque blob.
  • security.txt. Each binary carries a neodyme security.txt with a contact for reporting bugs, visible in the Solana Explorer Security tab.
Important

Neither program has had a third party security audit, and we say so in each repo. A verified build proves the code is what we published. It does not prove the code is free of bugs. Treat it that way.

The Terminal Vault is also upgradeable so a sell path bug can be fixed. The failure mode of that design is that a transaction reverts and retries, never that funds are lost, and any upgrade is itself visible onchain.

How the marketcap is read#

Both programs price the token from live onchain reserves, not a number someone submits. Before graduation they read the pump.fun bonding curve's virtual reserves, and after it graduates they read the canonical PumpSwap pool's reserves. They convert the SOL side to dollars using a Pyth SOL/USD feed, and they reject the price if it is stale, unverified, too uncertain, or quoted in the wrong token. If the oracle cannot be trusted at that moment, the action reverts rather than acting on a bad number.

Check it yourself#

  • Read either program on Solscan and open the Security tab for the contact.
  • Compare the onchain program against its GitHub source through the verified build listing.
  • For a marketing round, rebuild the merkle root from the published list and confirm it matches the root onchain.
  • After launch, read each vault's token account on Solscan to confirm the 50% and 3% balances.
Terminal VaultFirstJpXgzGf2oBDsEa2eAqez2fKJdAUJi6R7gP7PXbj
Marketing VaultFirstEdiieqh7C68MpvA4ZBkhvRvL7YanQP5CuJAifhM
Copied