An on-chain verification record of MolePin v2's omnichain token system, built on LayerZero V2 OFT, before external audit and mainnet deployment.
Status: ✅ Testnet verification complete (Phase 1 & Phase 2 core) Pending: External audit, multi-DVN stack, mainnet deployment Last updated: May 21, 2026
MolePin v2 is an omnichain fungible token system using LayerZero V2's OFT (Omnichain Fungible Token) standard. This repository documents the testnet verification trail: every conservation invariant, every safety primitive, proven on-chain across BSC Testnet, Base Sepolia, and Polygon Amoy, with identical contract addresses on all spoke chains.
The verification covers:
- Phase 1 — Conservation Core: Forward lock/mint, reverse burn/unlock, zero-leakage round-trip, and spoke-to-spoke mesh (BSC Adapter remains untouched) — all global supply invariants hold.
- Phase 2 — Feature & Safety Matrix: Sender-only blocklist (inbound mint
is never blocked → I2 preserved), asymmetric guardian pause (guardian can
pause but cannot unpause), and per-pathway pause (
pauseEid).
Throughout every test, BSC canonical totalSupply() remains exactly equal
to T = 6,942,151,277,013 × 10^18, the fixed global supply. Not a single wei
of leakage was observed in any round-trip test.
This is not the contract source code. It is the verification artifact — the trail of evidence that an external auditor, an investor, or a curious community member can follow to understand exactly what was tested, what passed, and what remains to be done before mainnet.
If you are looking for:
- Contract source code: held in a separate private repository pending audit
- Testnet contract addresses: see deployments.md
- Detailed phase-by-phase results: see phase1.md and phase2.md
- Architecture overview: see contracts.md
- Security model: see security-model.md
MolePin v2 follows a hub-and-spoke topology built on LayerZero V2 OFT:
┌─────────────────────────────────┐
│ BSC Testnet (Canonical Hub) │
│ │
│ MolePin (ERC20, MOL, 18dec) │
│ ↕ │
│ MolePinOFTAdapter (lockbox) │
│ │
│ totalSupply == T (fixed) │
└────────────────┬────────────────┘
│
LayerZero V2 Mesh
│
┌────────────────┼────────────────┐
↓ ↓ ↓
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Base │ │ Polygon │ │ Other │
│ Sepolia │ ←──→ │ Amoy │ ←──→ │ spokes │
│ OFT │ │ OFT │ │ (OFT) │
└─────────┘ └─────────┘ └─────────┘
- BSC Testnet holds the canonical
MolePinERC20 contract. ItstotalSupply()is the global cap — it never changes. MolePinOFTAdapteron BSC is the lockbox. When tokens move out of BSC, they are locked in the Adapter. When they come back, they are released. Token are not burned or minted on the hub.- Spoke chains (Base Sepolia, Polygon Amoy, and future chains) run
MolePinOFT. They mint on inbound, burn on outbound. TheirtotalSupply()fluctuates with cross-chain activity, but always equals exactly what is locked in the BSC Adapter (plus any other spoke's supply). - Spoke-to-spoke transfers (e.g., Base → Polygon) bypass the BSC Adapter entirely. The Adapter balance does not change. This was verified in Test D2.
Three independent invariants enforce supply integrity:
| Invariant | Statement |
|---|---|
| I1 (Global cap) | BSC MolePin.totalSupply() == T at all times |
| I2 (Adapter accounting) | MolePin.balanceOf(Adapter) == Σ(spoke totalSupply()) |
| I3 (Zero leakage) | After any closed round-trip, all balances return to the initial state, bit-for-bit |
If any of these break, the system is unsound. The testnet verification demonstrated that all three hold across forward, reverse, round-trip, and spoke-to-spoke flows.
Every spoke chain deploys MolePinOFT at the identical contract address:
0x721329120D1616Db01B26E5150ef3C995c925377
This is achieved via deterministic CREATE2 deployment through the canonical
Arachnid factory (0x4e59b44847b379578588920cA78FbF26c0B4956C), which is
deployed at the same address on every major EVM chain.
The address is derived as:
address = keccak256(0xff ++ factory ++ salt ++ keccak256(initcode))[12:]
Since the factory address, salt (MOLEPIN-OFT-V2), and initcode (bytecode +
constructor args) are identical across all spoke chains — and LayerZero V2
endpoint addresses are identical across EVM testnets — the resulting
deployment address is identical on every spoke.
The BSC hub is intentionally a different address. The canonical hub is a distinct role (it carries the lockbox), and its constructor takes BSC-specific arguments. This separation is by design.
This "BSC distinct, all other EVM chains identical" pattern serves both operational and identity purposes:
- Operationally, a single addressable contract identity simplifies documentation, integrations, explorer searches, and user education.
- The hub-spoke asymmetry is encoded directly in the address topology.
The same-address property does not extend to non-EVM chains (Solana, TRON's base58 representation), because they use different address formats. Where relevant, EVM-internal hex equivalence is the best that can be achieved.
| Test | What it proves | Result |
|---|---|---|
| A: Forward lock/mint | BSC → Base 100 MOL: lock on BSC, mint on Base | ✅ |
| B: Reverse burn/unlock | Base → BSC 40 MOL: burn on Base, release from Adapter | ✅ |
| C: Zero-leakage round-trip | After 100→40→60, all balances return to T / 0 / 0 / 0 | ✅ |
| D1: Re-seed BSC → Base 50 | Adapter holds 50, Base supply 50 | ✅ |
| D2: Spoke → spoke (Base → Polygon 50) | Adapter UNCHANGED at 50 ★ | ✅ |
| D3: Polygon → BSC unlock 50 | A second spoke can unlock from the hub | ✅ |
The critical invariant — BSC totalSupply() exactly equals T at every
checkpoint — was verified at every step.
After Test D3, the <ME> (deployer) balance returned to exactly T on BSC,
matching the initial state byte-for-byte. Zero leakage.
| Test | What it proves | Result |
|---|---|---|
| G: Sender-only blocklist | A blocked sender cannot send; but they can still receive (mint via LayerZero is never blocked) → I2 preserved | ✅ |
| H: Asymmetric guardian pause | Guardian can call pauseBridge(); calling unpauseBridge() as guardian reverts; owner can unpause |
✅ |
| H-extra: Per-pathway pause | pauseEid(40102, true) pauses only the BSC pathway |
✅ |
Test G's most important finding: when a sender is blocked, outbound is
revert with MOL: sender blocked, but inbound mint via LayerZero
succeeds. This is critical because if inbound were blocked, a LayerZero
message in flight could become stuck — burned on the source chain but unable
to mint on destination — creating an irrecoverable supply integrity break.
By only blocking outbound, the system preserves invariant I2 unconditionally.
Test H's most important finding: the guardian role is asymmetric. It can pause (fast emergency response) but cannot unpause (which requires owner, i.e., the slower, multi-party governance path). This is the standard pattern for production-grade emergency systems: trigger easily, recover deliberately.
This is a critical section. Testnet verification, even thorough, is not the same as audit assurance.
This verification:
-
Does prove: that the smart contracts, when deployed, behave as the design intends. Conservation, blocklist semantics, pause semantics — all validated against real on-chain state on three independent chains, with LayerZero V2 messages flowing through actual DVN and Executor infrastructure.
-
Does not prove: absence of vulnerabilities. Testnet behavior under cooperative conditions tells us nothing about adversarial conditions. Reentrancy, integer overflow / underflow in untested paths, signature malleability, MEV exposure, dependency vulnerabilities, oracle manipulation — none of these are evaluated by testnet runs.
-
Does not substitute for external audit. The Runbook explicitly gates mainnet on: external audit (by an independent firm), deterministic CREATE2 with same-address decision, independent multi-DVN stack, ownership → timelock + multisig migration, dependency lock, and explorer source verification. Today, only the first half of CREATE2 and basic single-DVN routing are in place.
The current single-DVN configuration (LayerZero Labs) is acceptable for
testnet but not for production. Mainnet will require at least two
independent DVNs in the Required set, ideally with a Confirmation count
that adds finality safety.
In order of priority:
- Test I — RateLimiter (opt-in cross-chain rate limiting): not yet
verified on testnet. Configuration of
RateLimitConfigstruct fields needs to be validated against the installed@layerzerolabsversion. - Test J — Slippage & dust: minimum amount enforcement and
_removeDustbehavior. On 18-decimal EVM chains_removeDustis identity, so this is primarily a code-review item; non-18-decimal chains (if added in future) require explicit attention. - Multi-DVN configuration: configure at least one independent DVN beyond LayerZero Labs (e.g., Google Cloud, Polyhedra, or Nethermind).
- TRON integration (post-audit): LayerZero V2 supports TRON Mainnet and Tron Nile Testnet as EVM-compatible chains. A TRON spoke can be added following the same architecture. This enables a clean migration path from the legacy TRC-20 v1 contracts to v2.
- External audit: scope to include the contracts, the deployment script, the wiring script, and the runbook.
- Ownership migration: from deployer EOA → timelock + multisig (Gnosis Safe recommended), with separate signer sets for owner and guardian.
- Dependency lock: pin all package versions, particularly LayerZero V2
dependencies, and commit a
package-lock.jsonsnapshot. - Block explorer source verification: verify all deployed contracts on BscScan, BaseScan, PolygonScan (and future chain explorers).
- Mainnet deployment: 8 EVM mainnet chains + TRON, with the same CREATE2 pattern and the same per-chain allocations (totaling exactly T).
- README.md — this document, the entry point
- docs/phase1.md — Conservation Core verification, in depth
- docs/phase2.md — Safety Matrix verification, in depth
- docs/contracts.md — Contract architecture, interfaces, and design notes
- docs/deployments.md — All testnet contract addresses, transaction hashes, and LayerZero Scan links
- docs/security-model.md — Threat model, invariants, roles, and known limitations
A complete Korean translation of this verification trail is available under ko/. The Korean documentation matches the English in depth and structure.
This document is deliberately conservative in its claims. The contracts have not been audited. They have been verified to behave as designed on testnet. That is a necessary condition for trustworthy mainnet deployment but not a sufficient one.
The verification work documented here represents the maximum due diligence we can apply ourselves, in-house, before bringing in an external auditor. We share it publicly because:
- An audit firm will review this trail; making it public means the community can review it too.
- Transparency about what has been tested — and what remains untested — is the only honest way to communicate the maturity of a system before it holds real value.
- The disciplined verification pattern itself (Runbook → execution → ledger → invariant check at every step) is something we encourage other token projects to adopt.
We will publish updates as we progress through the remaining items: audit engagement, multi-DVN configuration, TRON integration testnet, and the mainnet deployment.
The verification documents in this repository are released under CC-BY-4.0.
Contract source code (in the separate repository) is held under proprietary terms pending audit, after which it will be released under an open-source license to be determined.
For technical questions about the verification methodology, open an issue in this repository.
For audit firms interested in engaging on the next phase, contact information will be shared off-chain.
This verification trail surfaced a critical empirical finding: LayerZero V2's BSC↔Tron pathway does not deliver reliably for new OApps. Two test transactions remain INFLIGHT after 5+ hours with the LayerZero Labs DVN in WAITING state, while BSC↔Polygon worked perfectly (58 seconds, $0.06).
That finding drove the design of a self-operated cross-chain protocol:
→ molepin-mccp — MolePin Cross-Chain Protocol
MolePin v2 verification team — May 2026