Orbital, the first onchain privacy layer in Orbio's orbit

$REMUS · DuoFactoryPons · 2026-09-21 22:11 UTC

Remus

90

score · lower risk

7/8

signed by the auditor

ORBITAL SCORE
90/ 100

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.

Red flags
  • 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
Green flags
  • 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

  • 01
    No hidden mintpass

    Minting happens in the constructor only.

  • 02
    No owner drainpass

    Balances move only from the caller, or with an allowance.

  • 03
    Tax under the cappass

    TAX_DURATION, EXIT_TAX_BPS, PORTAL_FEE_BPS, TOKEN_TAXED_V3 cannot be changed after deployment.

  • 04
    No blacklistpass

    No per-address switch in the transfer path.

  • 05
    No pause on transferpass

    No switch in the transfer path.

  • 06
    Not upgradeablepass

    No DELEGATECALL in the runtime. The code that is sealed is the code that runs.

  • 07
    Sell path clearsnot run

    Not run: no wallet holds this token yet. Runs again after launch.

  • 08
    No 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 Blockscout

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
Read it on Blockscout

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.