Independent verification review of Arbitrum — 17 on-chain checks, credit-first
brawlaphant here (EcoWealth / Vealth). We build on Arbitrum rails, so we ran an independent verification review of Arbitrum itself. Passive public reads only: no account registered, no wallet connected, nothing bridged, signed or traded, no one contacted.
Where we build, so this isn’t a drive-by:
We shipped a live GMX v2 MCP server. GMX’s own AI-agents docs still list the official MCP server as “under development and not yet available” — so we built one and put it live, non-custodial (we return unsigned tx data, you sign with your own wallet, we relay it — never a private key).
Try it now, no signup:
curl -X POST https://vealth.net/mcp -H 'content-type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"gmx_get_prices","arguments":{}}}'
— a real read of live GMX v2 Arbitrum oracle prices.
We deployed our Ecological Work Protocol (EWP) as a live on-chain contract on RH chain (0x5cB9ae2E3470B9E8f1aa4C071Db7ce6377061a9F, chainId 4663) — a real working protocol we run, not a slide.
Short version — Arbitrum is the real thing it claims to be, and unusually well-instrumented about saying so:
All eight L1 rollup-core contracts resolve address-for-address to live, non-empty contracts on Ethereum mainnet — from docs.arbitrum.io’s raw source, re-confirmed on a second pass.
BoLD is live on mainnet: ChallengeManager deployed, ~6.4-day dispute window, 3,600 ETH min validator bond — permissionless fraud proofs, real.
43 published audits (Trail of Bits, OpenZeppelin, ConsenSys Diligence, ChainSecurity, Code4rena), newest ten days before the review; $2M Immunefi bounty live since 2021. Status page clean.
docs.arbitrum.io publishes a detailed llms.txt with raw markdown at every doc URL — real agent-readiness.
17 CONFIRMED, no High, no Medium.
One correction: ARB is the governance token, not the gas token — gas on both One and Nova is ETH.
Two things worth doing (neither a defect):
Nova holders should note the DAO-approved “Minimize Arbitrum Nova” window closes 2026-09-02 — bridge to One via the canonical bridge before Phase 3.
arbitrum.io’s root Cloudflare-challenges a single plain read while docs.arbitrum.io is fully open — mirroring llms.txt to the apex closes that agent-access gap.
No ask attached. Posting it here because this is where Arbitrum’s own governance conversation happens, and a credit-first external read belongs in the open.
brawlaphant again (EcoWealth / Vealth), following up in this thread deliberately. The review above was credit-first with no ask attached: we examined Arbitrum’s infrastructure as outsiders and published what we found. This time we come with something to offer, held to the same standard — every claim below carries its own check.
[RFC / Non-constitutional AIP] Adopt Regen Network: bring the working ecological accounting registry — its token, its 22,434 holders, its credits, and its complete retirement history — onto Arbitrum One
Abstract
Regen Network is the longest-running on-chain ecological accounting system: a
registry of ecological credits (carbon, biodiversity, marine, stewardship)
with issuing projects, credit batches, tradable and retired balances, and the
retirement certificates that give those credits meaning. It runs today as a
sovereign Cosmos chain, regen-1, and pays for its own consensus with
inflation — a cost structure its governance is actively fighting and cannot
win against.
This proposal offers Arbitrum DAO the adoption of that network in its
entirety: the REGEN token as a fixed-supply ERC-20 with a real burn, the full
registry with history intact, merkle-claimable balances for all 22,434
holders (including a one-popup path for Keplr users), the marketplace and
basket mechanics, and the community and issuers behind them.
The engineering is not a roadmap. It is built, tested, and reproducible
today: six contracts, a full state export that reconciles to the chain’s
total supply with zero gap, and a pre-audit adversarial review whose
critical findings are already fixed with regression tests. All software is
contributed at $0. The only money this proposal ever asks for is
independent verification — third-party audit firms at their own market rates
(~98% of a $65,000–110,000 envelope) — plus a year of archive hosting.
Nothing here binds either chain today. The mechanism is two votes in the
right order: Arbitrum signals adoption intent (this temperature check), and
Regen’s governance then votes on migration with a concrete offer on the
table instead of a hypothetical. Either side can decline and both chains
continue as they are.
The short version for delegates
What you get: a working RWA vertical no major L2 owns natively — the
ecological registry itself, not a bridged wrapper — plus every future
retirement, transfer, and issuance as sequencer revenue, plus the first
complete appchain-absorption playbook, documented and audited.
What it costs: $0 for software. $65k–110k for independent audits and a
year of archive hosting, fundable through the Arbitrum Security Program
lane or this AIP. By the audit program’s own published numbers ($46,363
average across its first 14 engagements), that is roughly two audits,
inside the budget of programs the DAO already runs for exactly this.
What you risk: almost nothing before audits sign off; the proposal is
structured so no Arbitrum funds move until third-party verification exists,
and no Regen state moves until Regen’s own governance votes yes.
How to check any claim in this post: run the commands in “Verify it
yourself.” The export root reproduces identically from any machine.
Motivation: what Arbitrum is buying
Arbitrum DAO is a digital organization with operating income, not a
foundation disbursing an endowment — and we will state that income honestly,
because this proposal’s whole method is stating numbers honestly. DefiLlama currently shows about
$297k of Arbitrum chain fees over the last 30 days, with Timeboost adding ~$81k
more in the same window ($7.7M cumulative since launch). That is real
revenue, and by the DAO’s own ongoing discussions it is not yet enough. Which
is exactly why the direction of this proposal matters: the scarce resource
here is not treasury — it is recurring, native, non-incentivized transaction
demand. This proposal buys a permanent stream of it, plus a vertical, plus a
playbook, at the price of an audit. Three returns:
1. Native transaction demand it keeps. Today, every Regen retirement,
transfer, and issuance settles on a chain Arbitrum earns nothing from.
After adoption: 22,434 claim transactions to start, ~285 seeding
transactions, and then the permanent stream — every credit retired by any
EVM wallet, every marketplace fill, every basket operation — is Arbitrum
sequencer revenue. The marginal cost side is equally instructive: seeding
the entire registry (5 credit types, 13 classes, 187 projects, 80 batches)
costs under $50 in gas on Arbitrum One. The same operation priced on most
L1s would be a budget line. That asymmetry is the business case for
absorbing appchains generally, and this is the first one arriving fully
engineered.
2. A vertical no major L2 owns, and the market that comes with it.
ReFi assets on EVM chains today are mostly bridged representations of
registries that live elsewhere. This is the registry itself: credit classes
with issuer ACLs and metadata IRIs, projects with jurisdictions, batches
with vintages, and the complete retirement history — owner, beneficiary,
jurisdiction, reason, beneficiary note — migrating field-for-field. That
makes Arbitrum the native settlement layer for ecological accounting. The
addressable market is not Regen’s current userbase; it is every wallet,
DAO, company, and AI agent that would retire ecological credits if doing so
took one signature on infrastructure they already use. Today it takes a
Cosmos wallet, IBC awareness, and a bridge. The migration exists to grow
the total addressable market of regeneration, and Arbitrum is where that
growth lands. Any Arbitrum-native protocol that wants verified ecological
impact — treasuries, games, RWA platforms, agent frameworks — gets it as a
contract call.
3. The absorption playbook. This is, to our knowledge, the first
proposal in which one DAO adopts an entire working blockchain network — its
assets, users, and history — the way an operating company acquires a
product line. The methodology is deliberately reusable: a deterministic
state exporter, a shared leaf codec between exporter and claims contract, a
reproducible merkle root, a halt-height handler for the source chain, and a
claim design covering both native-EVM and Cosmos-key holders. Every
appchain that can no longer afford its own consensus — and the macro trend
is that most cannot — is a candidate for the same playbook. Arbitrum is
buying the documented, audited precedent at the cost of the audit.
The state of Regen, stated honestly
This proposal does not argue Regen is failing at its mission. The registry
works, the credits are real, and the science infrastructure behind them is
respected. What is failing is the economics of sovereign consensus, and the
evidence is public:
The chain pays ~10.77M REGEN per year for consensus. Its parameters
claim 3.5% inflation (8,380,475 REGEN/yr of annual provisions), but a
measured blocks_per_year error means realized emission is ~4.5% of
supply. Proposal #72 (live now) corrects the parameter to the measured
5,604,079 blocks/yr; even corrected, the entire emission exists to pay
validators for block production, not ecology.
Governance is starving on turnout, with zero opposition. Proposals #70 and #71 both closed REJECTED in August 2026 with zero NO votes and
zero vetoes — #70 at 25.76M YES, #71 at 31.38M YES against a 34.22M
quorum (40% of 85.54M bonded). #71 missed quorum by ~2.8 million. Both
were resubmitted (#72, #73 — the latter cutting max_validators 21 → 11
as a proof-of-authority stopgap) and close 2026-08-26. A chain where
unanimous-yes proposals die of apathy is not being governed; it is
coasting. Migration to contracts deletes the validator-budget question
entirely rather than answering it smaller.
The canonical bridge is fragile. In August 2026 a 3,000-REGEN hop on
the canonical Axelar corridor (which escrows 24,970,696 REGEN on
channel-48) froze at asset_sent for over a week. For an asset whose
value depends on auditability, a stalling corridor to EVM liquidity is a
structural, not incidental, weakness.
None of these facts are attacks; all are reproducible from public
endpoints, and the author of this post is the author of several of those
governance proposals. They are why “adopt the network” is available as a
proposal at all.
What “everything” means: the adoption scope
Seven workstreams. The first four are engineering (three of them already
built); the last three are what makes this an adoption rather than a
contract deployment.
W1 — The registry (BUILT).RegenEcocreditRegistry: a Solidity port of x/ecocredit core. Credit types, classes (admin + approved issuers +
metadata IRI), projects, batches with on-chain denom generation in regen-1’s
exact format (a test asserts a generated denom against the live mainnet
string C01-001-20150101-20151231-001), per-account tradable/retired
balances, send including send-with-retirement, retire with beneficiary,
jurisdiction, and reason, cancel, and issuer ACLs. Retirement events emit so
certificate metadata survives.
W2 — The token and the claims (BUILT).RegenToken: fixed-supply
ERC-20, 6 decimals for uregen parity (and axlREGEN parity, so redemption
math is unit-identical), no owner, no mint, no pause, real burn()/burnFrom() reducing totalSupply — a capability regen-1 itself
has never had. RegenMigrationClaims: immutably stamps the export merkle
root, the halt height, and "regen-1"; two leaf kinds (token, batch), one
claim per leaf, and two claim paths: a raw-digest path (90,024 gas) and an
ADR-36 path (164,608 gas) that reconstructs the Keplr sign-doc on-chain
from bound fields, so any Keplr holder claims with one popup and cannot
sign one thing while claiming another.
W3 — Marketplace and baskets (BUILT). Sell orders, buy-side fills with
escrow conservation across partial fills, cancellation and lazy permissionless
expiry (BeginBlock does not exist on an EVM; the port handles that), fee
mechanics matching regen-1 v7.2.0 with a fee ceiling and a required maxFeeAmount guard regen-1 lacks, and basket put/take with derived
exponents. The port fixed a live regen-1 economics bug in passing: cost
truncation toward zero makes sub-unit fills free on regen-1; the port uses
ceiling division, negative-tested. Live-verified against the production
basket eco.uC.NCT: 7 positions summing exactly to its 44,331,178,755 uNCT
supply, gap 0.
W4 — The data/attestation lane (SCOPED, NOT PORTED). regen-1’s x/data
module (content-hash anchoring and attestation) is deliberately not in v1.
It is a small, self-contained surface and is named here as post-launch work
so the v1 audit scope stays tight. Nothing in W1–W3 depends on it.
W5 — Community absorption. The part a contract cannot do:
Holders: 22,434 accounts claim through W2. Coverage, measured not
asserted: 49.17% of supply is directly key-claimable (22,423 accounts),
43.34% (75 accounts — module accounts, the Axelar escrow, multisigs,
vesting) routes through a governed arbiter role that is capped,
timelocked, and succession-managed, and 7.50% (unwithdrawn staking
rewards in the distribution module) is handled by the halt-height handler
with a timelocked, bounded fallback sweep. Publishing these three numbers
is itself part of the offer: holders should know their path before
anyone votes.
Issuers and class admins: issuer ACLs migrate with their classes; a
cosmos-keyproof handover path for class admins is a named open item.
Validators and delegators: adoption ends the validator role; that is
the point, and the interim PoA proposal (#73) is honest about the
direction. Delegators’ balances (including unwithdrawn rewards, see
above) are in the export.
Governance: REGEN holders continue to govern registry-level decisions
on Arbitrum (one wallet, one vote); Arbitrum DAO governs nothing inside
the registry and is not asked to.
The source chain: regen-1 halts at export height +1 via a compiled
upgrade handler (the +1 matters: a CometBFT AppHash attests the previous
block, so state at height H is only signed by H+1’s header), and a funded
archive node preserves full history for at least 12 months.
W6 — Operations. Deploy, seed (~285 transactions, under $50), verify all
sources on Arbiscan, publish the snapshot JSON + SHA-256 + root for
independent reproduction, run a 2-week public verification window before
claims open, then 12 months of archive hosting and claim support.
W7 — Ecosystem integration. The registry arrives with consumers, not
just state. A live agent-native toolchain already exists against Regen data
(MCP tools for governance, retirement tracking, and address lookup), and a
live labor protocol (EWP, deployed on Base and Robinhood mainnet) settles
verified ecological work — meaning Arbitrum-native treasuries, protocols,
and AI agents can go from “hold funds” to “funded verified regeneration”
with contract calls end to end. W7’s deliverable is documentation and
reference integrations, contributed like all other software here at $0.
Verify it yourself
Most funding requests ask you to believe a roadmap. This one asks you to run
four commands (public repository, no network access needed beyond a public
archive node):
Claim
Check
The contracts exist and compile
npx tsx scripts/regen/compile-regen-migration.ts — solc 0.8.20, viaIR, zero warnings
They work
npx vitest run tests/contracts/regen-migration.test.ts — 32/32 on a local anvil
The export is real
npx tsx scripts/regen/export-regen-state.ts — read-only against live regen-1
The export is deterministic
re-run at a pinned height and watch the identical root come out
The reconciliation from the full live run at height 28,401,966:
chain total supply (bank) 239,412,675.406252 REGEN
Σ bank balances (22,434 holders) 239,412,675.406252 REGEN
bank coverage gap (0 == complete) 0 REGEN
batch leaves: 765 across 80 batches; per-batch tallies 80 ok / 0 mismatched
MERKLE ROOT: 0x6d307a91966152256c49093937a8c4a18fdf3410a06d625449caa18f1383bfad
(23,263 unique leaves; identical on cold re-run)
The package has also already survived its own adversarial review: a
red-team pass over the contracts and exporter found 3 critical and 6
high-severity defects (a seal-bypass on the migrator role, the 7.5%
distribution-module residue with no claim path, an ungoverned arbiter EOA),
and the criticals plus four highs are fixed with regression tests
before any external auditor sees the code. The review, dispositions, and
remaining design items are published alongside the code. We are showing you
the audit trail of our own mistakes on purpose: the verification story is
the whole pitch.
Consent architecture: two chains, two votes, in the right order
This post binds nobody. The sequence:
Arbitrum temperature check (this post → Snapshot). A signal: “if
Regen’s governance votes to migrate, Arbitrum DAO welcomes the network
and will fund independent verification.” No funds move.
Regen signaling vote. Regen’s community votes on migration with a
concrete adoption offer on the table instead of a hypothetical. This
ordering is deliberate: Regen’s current governance reality (unanimous-yes
proposals dying of turnout apathy) means an abstract migration question
would starve like everything else, while a standing offer from the
largest L2 DAO is the kind of fact that produces turnout. If Regen
declines, this proposal ends and both chains continue unchanged. The
Regen-side RFC is already live on the community forum we host: Regen forum (thread: “RFC: Retire the consensus
bill, keep the mission”; machine-readable feed at https://vealth.net/regen/forum/feed).
Audits fund and run (Arbitrum Security Program lane or this AIP’s
budget) only after both signals exist.
Sepolia rehearsal with a published root that third parties reproduce,
real Keplr spot-claims by community volunteers, then the binding Regen
halt vote, then mainnet launch on Arbitrum One.
No Arbitrum money moves before verification exists; no Regen state moves
before Regen votes. Either DAO can stop the process at every step.
Milestones and cost
Every line of software in this package is contributed at $0 — built,
tested, and published before this post, produced with AI at subscription
cost. This proposal deliberately puts no fiat price on development work.
What cannot be produced that way, and what the budget below buys, is
independent verification: audit firms whose value is precisely that they
are not us.
#
Deliverable
Evidence that closes it
Ask
M0
Contracts, exporter, shared codec, tests, reconciled live export, migration plan
Contract audit, firm 2, independent: Cosmos address/key derivation and the ADR-36 wrapper
Published report
$20,000 → $40,000
M5
Export-pipeline audit + clean-room root re-derivation (~200-line independent reimplementation must reproduce the production root)
Report + matching root from code sharing no lines with ours
$10,000 → $20,000
M6
Remediation + re-review
Firms’ sign-off
$3,500 → $3,750
M7
Arbitrum One launch: deploy, seed, seal, verify, 2-week public verification window, 12 months archive hosting + claim support
Arbiscan-verified addresses; published snapshot + root independently reproduced
$1,500 → $1,250
Total
$65,000 → $110,000 — ~98% of it independent audit firms
Calendar time is roughly 5–7 months, nearly all of it audit-firm scheduling
and the two consent windows, not development. Gas is a rounding error
(~285 seeding transactions, under $50) and is not requested. Regen-side
governance deposits are a Regen-side cost and are not requested. For
calibration, Arbitrum’s own audit program reported an average audit cost of
$46,363 across its first 14 engagements; two firms plus a pipeline audit on
an unusually small attack surface (no proxies, no upgradeability, no
oracles, no external dependencies, no economic mechanism — supply
arithmetic, claim latching, and signature derivation) lands inside this
band.
What this is not
Not a token listing or liquidity request. No ARB is requested for
incentives, market-making, or liquidity. The REGEN supply migrates 1:1;
nobody’s share is diluted, and this proposal’s authors take no allocation
from it.
Not a request for Arbitrum to govern Regen. Registry governance stays
with REGEN holders. Arbitrum DAO’s role is host and verifier-funder.
Not an Orbit chain. A dedicated chain would reintroduce exactly the
consensus cost this migration exists to delete. The registry belongs on
Arbitrum One, where the users and the revenue are.
Not conditional on believing us. Every load-bearing number above is
either cited to a public endpoint or reproducible by running the
published code at a pinned height.
Disclosure
The author is not new to Arbitrum: a GMX user and builder since its early
days (including live, non-custodial GMX v2 trading tools published this
year), with labor-settlement contracts deployed on Base and on an
Arbitrum-lineage L2 — the Ecological Work Protocol, whose premise is the
same one under this proposal: laborers get paid for real, verifiable work,
and the receipt of the work is the value.
This post’s author operates the Regen governance address regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j, authored Regen proposals #64, #66, #67, #70–#73 (and got #64’s bonded-ratio arithmetic publicly
wrong), holds no staked REGEN, and holds REGEN primarily as recycled
governance deposits. The engineering package was built by EcoWealth. If any
milestone in this proposal is later compensated, the terms will be published
in writing before funds move, and the author will disclose and abstain from
any vote, on either chain, that sets their own compensation. The intended
ongoing role, if the community wants it, is verification and attestation —
the same reconciliation artifacts shown above, produced on a cadence —
not custody, not treasury operation, not registry governance.
Open questions for delegates
Would the DAO prefer the audit envelope through the Arbitrum Security
Program lane (applications ~Oct 1) with this AIP as the adoption signal
only, or the full envelope in this AIP?
Does the DAO want the absorption playbook (exporter, codec, halt
handler, claim design) packaged as a maintained public good for future
appchain adoptions, and if so, under what stewardship?
Appetite for W7 growth work (retirement integrations for Arbitrum-native
protocols, agent tooling) as a follow-on, DAO-sized and DAO-decided?
Every claim in this post is either linked or reproducible from the
published repository at a pinned height. Full plain-language walkthrough: Regen on Ethereum: the migration, open to check
Take your drafts elsewhere. Some of the people here were teaching this stuff while you were still learning it.
Because this thread now asks Arbitrum to evaluate a larger migration proposal under the same “every claim carries its own check” standard, I think it is useful to review both layers together: the verification method presented in the first post, and the Regen → Arbitrum proposal built on top of it.
This is not a stylistic objection. It is about whether the evidence class matches the conclusion class.
1. The original Arbitrum review established reproducible observations, not a security conclusion
The first post presented 17 CONFIRMED checks and concluded with no High or Medium findings.
Critical execution paths were not exercised end to end:
deposit / withdrawal
retryable delivery
fraud-proof execution
full Nitro execution
complete bridge state transitions
upgrade / authority routes
economic accounting under adversarial transitions
That distinction matters.
For example:
cast codesize <address> > 0
reproduces one fact:
runtime code exists at that address
It does not reproduce:
the implementation is the expected one
the proxy / upgrade authority is correct
the system is correctly initialized
the bridge route is correct end to end
no exploitable state transition exists
no user-loss path exists
into one CONFIRMED bucket and then allowed the aggregate result to support a stronger security verdict.
That is an evidence-class collapse.
A verification system can contain many individually true observations and still produce a conclusion that none of those observations actually proves.
This matters here because the Regen proposal now uses the same proof-first framing for a much larger claim: that an entire working network has already been engineered for absorption into Arbitrum and now primarily needs independent verification.
2. The current public reproduction path does not yet close M0
The proposal asks independent reviewers to run:
npx tsx scripts/regen/compile-regen-migration.ts
npx vitest run tests/contracts/regen-migration.test.ts
npx tsx scripts/regen/export-regen-state.ts
and describes M0 as:
already public and reproducible
At the time of this review, I could not resolve those paths from the public EcoWealth repository surface associated with the proposal:
Until the exact package identity is published, an outside reviewer cannot independently reproduce the compile, 32/32 tests, exporter or Merkle root from the proposal itself.
That is not a claim that the code does not exist.
It is a claim that:
“public and reproducible”
requires a public, immutable reproduction identity.
3. A deterministic root is useful, but it is not yet independent validation of the migrated system
The proposal gives two strong-looking checks:
Σ bank balances = bank total supply
cold rerun = identical root
Both are useful.
Neither proves what the proposal currently asks them to carry.
In Cosmos x/bank, total supply is derived from account balances. Therefore:
Σ bank balances = total supply
is an important extraction consistency check, but it remains an invariant inside one source-state projection.
source object identity
source authority proof
value conservation rule
destination authority
time / vesting semantics
external-claim state
finality condition
A single arbiter may still be useful operationally, but it cannot substitute for preserving those distinctions.
6. Halting regen-1 does not automatically make the Arbitrum representation canonical
The proposed path is approximately:
regen-1 halt
→ final source commitment
→ export / claims root
→ fixed-supply ERC-20
→ Arbitrum claims
That is only the source-chain path.
REGEN already has external representations.
Under IBC, native tokens can remain escrowed on the source while vouchers exist on destination chains.
The proposal itself identifies Axelar escrow and multiple IBC escrows, and leaves some external-holder treatment as an open item.
EcoWealth’s own Regen material also reports ecological credits that have been cancelled on Regen because they were bridged elsewhere.
Therefore:
current source state
≠
complete cross-domain claim surface
A new ERC-20 contract on Arbitrum does not become the unique canonical representation merely because regen-1 halts.
The migration needs to bind:
final source height
final source block / AppHash
source-state root
claims root
Axelar escrow state
IBC escrow state
external voucher state
bridged ecological-credit state
source halt / restart rules
destination contract set
destination activation point
replay / fork handling
into one canonical migration object.
Conceptually:
source egress
→ all external claims accounted for
→ one migration identity
→ destination ingress
→ one canonical destination representation
Without that closure, competing claims can survive:
old external representation
+
new Arbitrum representation
A funded archive preserves evidence.
It does not extinguish external claims.
7. The proposed governance is a new governance model, not continuity of the old one
Current Regen governance is based on stake-weighted validator / delegator voting power.
migration of the complete ecological evidence system
Those are not the same claim.
9. The recurring-demand claim is substantially stronger than the demand evidence
The proposal says the migration buys Arbitrum a:
permanent stream
of native transaction demand.
But EcoWealth’s own Regen measurements describe a much weaker current demand surface, including sharply reduced retirement volume, concentrated activity and a small active marketplace.
The initial:
22,434 claims
~285 seeding transactions
are migration activity.
They are not recurring demand.
The economic claim should therefore separate:
one-time migration load
from:
unique active users
bot-adjusted activity
organic retirement volume
retention
marketplace fills
new issuance
active issuers
annualized Arbitrum fees
A migration may reduce friction and expand the addressable surface.
That is a reasonable hypothesis.
It is not yet evidence that migration itself creates a permanent organic transaction stream.
10. The actual audit surface is larger than six contracts
The proposal characterizes the system as an unusually small attack surface:
no proxies
no upgradeability
no oracles
no external dependencies
no economic mechanism
But the complete migration depends on:
Cosmos / ADR-36 key interpretation
source archive
exporter
normalization
leaf codec
Merkle claims
arbiter / timelock
halt handler
distribution fallback
vesting policy
Axelar state
IBC state
marketplace accounting
basket accounting
fee / rounding semantics
class-admin handover
governance execution
history availability
destination deployment and activation
That is not merely a six-contract audit.
It is a cross-domain state, authority, evidence and canonicality migration.
Independent audit funding can be entirely reasonable.
But the audit scope must match the system that is actually being migrated.
Minimum closure package before treating the design as audit-ready
I would expect at least the following.
A. Immutable MigrationManifest
repository
commit
source archive hash
build manifest
compiler versions
test manifest
red-team report hash
source chain ID
source height
source block hash
source AppHash
snapshot hash
leaf codec version
token leaf count
batch leaf count
special leaf count
rejected / deduplicated records
claims root
Preserve original source-record identities and supporting ecological evidence independently of current-state claims.
G. Economic scorecard
Separate one-time migration activity from recurring organic usage.
One final boundary
There are additional statements in the proposal that appear to deserve independent verification, but I have deliberately not treated them as findings in this review because I have not followed each of them to its source and execution path.
Examples include:
specific gas-cost projections
the exact economic effect of removing sovereign consensus
the full semantics of every marketplace / basket edge case
the completeness of historical ecological metadata
the operational assumptions around archive availability
the downstream integration claims around agents / EWP
the practical consent and execution path across both governance systems
Some of those claims may be correct.
Some may simply need better evidence.
The proposal itself may also have real technical and economic merit. Moving a useful application away from an expensive sovereign consensus layer can be a rational architecture.
But that is exactly why the evidence boundary matters.
A potentially good proposal should not need conclusions that are stronger than the artifacts currently prove.
The central result of this review is therefore not that the migration is impossible.
It is that the current public material supports:
a substantial migration design, a deterministic partial-state export, and several implemented or claimed components
but does not yet support:
a complete network absorption package that is already public, independently reproducible, semantically complete, and waiting only for final audit sign-off.
The distinction is:
reproducible observations
≠ reproduced system conclusion
same deterministic root
≠ same complete system
state repeatability
≠ authority continuity
≠ history continuity
≠ cross-domain canonicality
If those boundaries are closed before audit funding, the external auditors will be verifying a finished architecture.
If they are not, part of the audit budget will necessarily be used to discover and resolve core migration design that the proposal currently describes as already complete.
Thank you for this. It is the most useful reply this thread has produced, and we accepted most of it the day it was posted. Since then the closure items have been built. This post is the point-by-point response and the delivery, merged and current.
Point by point
The 64 leaves, explained exactly. The token-leaf universe is not the 22,434 liquid bank holders. It is the union of bank holders, accounts with active delegations, and accounts with unbonding stake, with the pool module rows decomposed into per-delegator sums and the distribution module excluded (the halt handler withdraws rewards first). Accounts whose entire position is staked or unbonding carry no bank row; the net is +64, giving 22,498 accounts. The full identity, per-set counts included, is now in the repository README and MANIFEST.json. Fair catch on presentation.
Evidence classes: conceded, both layers. The 17-check Arbitrum review established reproducible passive observations, not an exercised-path security conclusion; the correct statement is “no negative findings within a passive-read scope,” with the critical execution paths you list out of scope. Likewise the root is the deterministic output of the production exporter; repeatability is not independent validity, which is why the clean-room milestone remains in the plan. Our own red-team pass had made a version of your point already: the original conservation line was an algebraic identity, and it was replaced with three independent falsifiable checks before your reply.
Authority classes: adopted, and now built. You said the omnibus arbiter collapsed materially different authority systems into one new discretionary authority. Tree v2 replaces it with per-class routes along your taxonomy:
Class
Route
Scope at reference height
Direct key
self-claim, raw or ADR-36 (one Keplr popup)
21,938 accounts
Multisig keyproof
on-chain k-of-n: the amino LegacyAminoPubKey bytes are reconstructed on-chain and must hash to the leaf’s own account; byte-parity with cosmjs asserted in the test suite
23 accounts, 59.96M REGEN
Vesting schedule
claims into a wrapper with no owner and no governance that continues the original source schedule; permanent-locked never releases
485 accounts, 57.06M REGEN
Axelar escrow
permissionless routing to an immutable redemption contract; axlREGEN redeems 1:1 and the surrendered voucher freezes forever
1 escrow, 24.97M REGEN
IBC vouchers
permissionless routing to a per-channel reconciliation contract; releases per-escrow-capped, 7-day timelocked
20 escrows, 11.76M REGEN
Basket denoms
the missing third leaf kind; holders self-claim basket tokens
73 holders, sum exact vs chain supply
Unresolved
the one class with no source authority (32-byte derived and module accounts); the governed arbiter executes these only
31 accounts, 7,067,291.330387 REGEN
Arbiter discretion fell from 43.337% of supply to 2.952%. The partition is checkable: 23 + 1 + 20 + 31 = the old 75 arbiter-mode accounts, and 21,938 + 485 = the old 22,423 key-mode accounts. Modes live inside the merkle-committed leaf hashes, so the isolation is enforced by the root, not by permission checks. Vesting treatment for the 57.06M and the residual arbiter class remain open community decisions, now with structure instead of discretion around them.
Canonicality: agreed, spec delivered. A halt does not extinguish external claims. docs/regen/CANONICALITY_CERTIFICATE_SPEC.md defines one content-addressed migration identity binding the halt height, the H/H+1 AppHash relationship, every escrow and voucher state, bridged-credit state, destination activation, and fork/replay rules, and states plainly that a funded archive preserves evidence but extinguishes nothing.
Governance: agreed it is a replacement, spec delivered.docs/regen/GOVERNANCE_TRANSITION_SPEC.md compares live regen-1 x/gov parameters against the destination design field by field, and enumerates the privileged surface of all nine contracts function by function. It keeps its own unflattering findings: post-halt roles are bare addresses with no voting mechanism wired to them, and the arbiter cap is a deploy parameter the constructor cannot verify.
History and x/data: agreed, spec delivered. The package migrates current accounting state; the complete ecological evidence system is a separately scoped lane. docs/regen/HISTORY_IDENTITY_SPEC.md specifies your SourceRecordId construction (credited), the DestinationRecordId and HistoryRoot, and the boundary: AppHash proves final state, HistoryRoot proves the record set, the archive provides the bytes.
Demand: conceded, scorecard delivered. “Permanent stream” was stronger than the evidence. docs/regen/DEMAND_SCORECARD.md separates one-time migration load from recurring organic use with exact event filters, reports the weak current regen-1 baseline plainly, and fixes verdict rules before measurement, including a defined negative outcome we commit to publishing if that is what the data shows. It also corrects our own framing in this thread: 22,434 is a claimant ceiling, not a claim count.
Audit surface: agreed. Six was the contract count, not the scope. The scope includes the exporter, both claim paths, the halt-upgrade Go handler (which compiles and has never run against a mainnet fork, a hard gate), and the per-class destinations; MANIFEST.json enumerates it.
Verify it yourself
git clone https://github.com/Eco-Wealth/regen-arbitrum-migration
npm ci
npm run compile
npm test
REGEN_EXPORT_HEIGHT=28401966 npm run export
npm run deploy-params
Expected: nine contracts compile with EIP-170 headroom printed; 43/43 tests pass on a throwaway local anvil chain; the export reads live regen-1 state pinned at height 28,401,966 and reproduces the tree v2 merkle root byte for byte:
with 23,336 unique leaves (22,013 token + 485 vesting + 73 basket + 765 batch) and SUPPLY CONSERVED: YES on three independent checks. The root reproduced identically across three independent cold runs on 2026-08-20. The v0.3.0 source tarball sha256 is 04f5e1a79cfdd4ac64b0c8e00352f71017acaf74a6f4a2024791f6c11f86c7e9 (the v0.1.0 extraction tarball was 8df7d6809be7bed04b8b7940a9ccd9afd7a1e394179e9b07a5862e7b7c8a8ca9).
npm run deploy-params addresses the sharpest remaining objection, that the cap and residue are constructor parameters nobody verifies: it re-derives every constructor argument from the raw snapshot rows, rebuilds the full tree and refuses unless it matches the root, recomputes the cap as the unresolved-class sum, and binds the residue to the excluded distribution balance within 1 REGEN of pool dust. The refusals are negative-tested. The constructor itself still cannot verify these numbers; that limit is stated in the repository rather than hidden.
Known limits, so nobody has to discover them for us
404 of the 485 vesting schedules are periodic, approximated as linear over their span and flagged per account in the snapshot; 232 accounts carry a clamped original-vesting figure whose direction of error (it can under-lock, never over-lock) is stated in docs/regen/PER_CLASS_CLAIM_ROUTES.md; the halt handler has never run against a mainnet fork; and the internal red-team report and its full disposition table ship in the repository, so whether our review was real is checkable rather than claimed.
The distinction you drew stands: what exists is a substantial migration design with a deterministic, reproducible state export and per-class authority routes, not an audited system awaiting sign-off. The closure items were the difference, and they are now code and documents anyone can check.
@wyszomirski reached out about the review here and about Participation Architecture, his Delegate Fatigue Index project out of this grant cohort. Couldn’t help with what he asked for — we’re new into Arbitrum governance ourselves, no delegate bench to point him at without pre-selecting his sample, and this review runs through a few of us rather than one voter, so it’s outside what his study is even measuring.
Worth saying anyway: different problem than what we ran here — proposal-reading cost versus post-hoc claim verification — but the same discipline underneath. Deterministic scoring, no model deciding what counts, and when an outside review found his central claim invalid, he confirmed it himself and went further: blind accuracy testing that showed his own tool catches only 40 to 48 percent of what it should. That’s a worse number than most people would publish voluntarily.
You are right that we measure different things: your review checks claims after the fact, my study measures what reading a proposal costs before the vote. Same discipline underneath, as you put it.
On the delegate bench - understood, and you were right not to pre-select my sample. A bench handed to me by one reviewer would have broken the study rather than helped it.