$REMUS · DuoFactoryPons · 2026-09-21 22:11 UTC
Remus
score · lower risk
signed by the auditor
Lower risk
Computed on 93% of the scale: what did not run is left out, not counted as zero.
- Checks
- 52.5 / 52.5
- Code analysis
- 23 / 25
- Review
- 8 / 15
A non-upgradeable launch factory whose owner can retroactively rotate the operator, porter, scorer and treasury that govern every coin's vault and staking contract.
- Token logic is hand-written rather than inherited from a widely reviewed base.
- setPorter grants signing power over vault inventory
- setOperator and setScorer rotate retroactively
- setTreasury redirects the platform share
- bonus pot locked without scorer signature
- portal refunds depend solely on porter
- opening buy uses a one-unit minimum out
- ten percent exit tax in unstake
- No owner-only function can change state after deployment.
- Every address the contract pays or calls is fixed at deployment (PONS_LAUNCHER, PONS_FACTORY, FLAP_PORTAL_BNB).
- No tx.origin, no inline assembly.
- Supply is fixed after deployment.
- The tax is constant.
- No proxy, no self-destruct: the sealed code is the code that runs, for good.
- two-step ownership transfer
- MAX_TAX_BPS caps tax at five percent
- immutable market and clone implementations
- deterministic duoId blocks pair hijacking
- no withdrawal function in the vault
- per-call and per-day spend caps
The code analysis, signal by signal
- Owner-only functions that change state · none10 / 10
- Addresses that can be changed after deployment · none5 / 5
- Dangerous primitives · none5 / 5
- Token foundation · hand-written3 / 5
The eight checks
- 01No hidden mintpass
Minting happens in the constructor only.
- 02No owner drainpass
Balances move only from the caller, or with an allowance.
- 03Tax under the cappass
TAX_DURATION, EXIT_TAX_BPS, PORTAL_FEE_BPS, TOKEN_TAXED_V3 cannot be changed after deployment.
- 04No blacklistpass
No per-address switch in the transfer path.
- 05No pause on transferpass
No switch in the transfer path.
- 06Not upgradeablepass
No DELEGATECALL in the runtime. The code that is sealed is the code that runs.
- 07Sell path clearsnot run
Not run: no wallet holds this token yet. Runs again after launch.
- 08No self-destructpass
No SELFDESTRUCT in the runtime.
The review
An opinion, signed by the auditor. Written by claude-opus-5.
DuoFactoryPons is not a token. It is the control plane for a launch system: each call to `launch` mints nothing itself but deploys a Pons V2 bonding-curve token through the Pons launcher, clones a `DuoVault` and a `DuoStaking` at addresses derived from `duoId` (creator address plus a chosen nonce), performs the opening buy with the sent value minus Pons's live `launchFee`, and splits the purchased tokens 30% to the staking bonus pot, 30% to the vault as parity inventory, 40% to the launcher, refunding any curve overflow. `predict` and `duoIdOf` let a creator reserve the same id on the other chain, which is a sensible anti-hijack design.
The important thing a holder cannot see from the token: the vault and staking clones read `operator`, `porter`, `scorer` and `treasury` live from this factory on every call. So whoever owns this factory indirectly controls, for every coin ever launched by it, who may trade vault inventory (`setOperator`), who may sign token releases out of any vault to any address via `portalIn` (`setPorter`), who receives the platform's tenth of all vault income (`setTreasury`), and who decides the weekly chain-war result (`setScorer`). Rotation is instant and applies retroactively to live coins. Ownership moves in two steps, which is good, but there is no timelock and nothing renounced. `setTerms` caps creator tax at 5% and only affects future launches; existing coins keep the tax Pons fixed at creation.
Two dependencies with no fallback: the bonus pot in staking only releases on a scorer signature, so an absent scorer leaves it locked indefinitely; and portal deposits, plus their refunds, both require a porter signature, so tokens handed to a vault via `portalOut` have no permissionless recovery path. Also note the opening buy is submitted with a minimum-out floor of one unit, so the launch purchase has effectively no slippage protection, and `unstake` permanently keeps 10% of any position.
Constructor-time: market, vault and staking implementations are immutable, but owner, operator, scorer, porter and treasury are all deployer-chosen and may be the same key.
Bottom line: the code cannot drain you, but one factory owner can rotate the keys that move every vault's token inventory and redirect the platform's fee stream at will.
What the seal names
- Code hash
- 0xb857b3aa00f940c6ea1e43139d0dab3f09c8b2940630ce3d4a1c92f129ee1da2
- Contract
- 0x59eb9157A24bF41F3758eF85a8F62e03c19b3E66
- Commit
- 15008a896df802d2431cc2cf7724b8964649466c
- Compiler
- 0.8.26+commit.8a97fa7a
- Auditor
- 0x4Abb70FCA576Ad3342b0622469BC2d5064274470
- Signature
- 0x34218105da3acf324c58b0b7ae7de8732f6011d67c41f8a1e5b3e6ac5e071755740b79300bf8cd01af2ea5c301bc76468a4763a9a09cfed67d689fcca18019731c
On Robinhood Chain
- Registry
- 0xeaDdD9E4dA832395BDCcD658e9EaCD1725ddFeEA
- Record
- 90/100 · 7 of 7 · signed · standing
- Bond
- 0 ORBITAL (no bond set yet)
- Written
- 2026-09-21 22:11 UTC
- Transaction
- 0x66f4e41855e959dfdfd0685e7bb798d01f5df62f3b14dd97a7539d7beea93542
The signature is over the code hash, the eight answers and the review text, by the auditor's key. The repository and the source are not on this page and not on the chain: the commit hash is what the auditor read, and only the auditor can say what it contained.
A seal is a floor. What it cannot see.