Security model

What is enforced by bytecode, what is operated by us, and exactly where the trust boundaries sit.

This page is deliberately unvarnished. Security claims in this space are usually marketing; ours are scoped statements you can check. Three categories: what cannot happen, what we operate, and what you should know.

Enforced by bytecode: cannot be changed by anyone

• The holder share cannot be redirected. The 24% travels through an immutable, ownerless splitter: no owner, no setters, recipients fixed at deploy. The fee-distribution legs feeding it carry genesis floors in bytecode, so no configuration on any path can move the holders’ money elsewhere.
• Launch-time choices are permanent. The creator/buyback slider, anti-sniper setting, and earnings splits are written once with no setters.
• Liquidity is protocol-locked. There is no liquidity-pull path for creators or for us.
• Escrows pay only their owners. Creator revenue, referral cuts, and X-handle escrows each pay exactly the address their on-chain records designate. The platform holds custody of none of them.

Operated by us: the honest trust list

• The payout keeper. A service closes epochs, runs the published formula, publishes each dataset, and submits roots. It is trusted to compute honestly, which is why every dataset publishes before submission and every root waits out a one-day public review, during which a wrong root can be challenged and revoked. See Verify any payout.
• The distributor owner. The rewards distributor’s owner role can technically bypass the timelock. Operationally this key is being moved to a multisig; until fully decentralized, this is a real trust assumption and we list it as such.
• The X verification signer. For handle recipients, a platform key attests handle-to-wallet bindings after an X login. Its power is limited to binding; it can never move escrowed funds.
• The protocol owner. Can lower the total swap fee or grant fee exemptions (shrinking every party’s income proportionally, never redistributing it), within caps fixed in bytecode.

Audit lineage, precisely stated

• The holder pool’s vault is Morpho’s Universal Rewards Distributor, a widely used contract audited by Cantina (managed review), OpenZeppelin, and a Cantina security competition.
• The launchpad contracts derive from the Flaunch protocol codebase, which has undergone multiple third-party audits, most recently Enigma Dark’s security review of the Flaunch v1.1 protocol upgrade (March 2025). Our modifications are concentrated in the fee-model configuration and the Arc port. They reroute fee shares between recipients fixed at deploy; they add no proxy or upgrade path, no minting, no custody, and no new admin power. Nothing in them creates a path to pull liquidity or seize user funds, and the “enforced by bytecode” guarantees above are properties of the modified code itself.
• The distributor is audited; the contract lineage is audited; our composition of them is published, verified on-chain, and open to inspection.

Known limitations, disclosed

• Smart-contract wallets (Safes, smart accounts, delegated EOAs) are excluded from holder-income eligibility at v1 by the formula’s no-code rule. Hold with a regular wallet to earn.
• Referrer identity is per-swap data set by the originating frontend, inherent to the referral design.
• ubi.fun runs on Arc testnet today. Everything on this page describes the mechanics that ship; testnet balances are not money.

Found something? Contact us on X or Telegram (@ubidotfun). No forms.