DeFiPunk'd

Railgun

Privacy

TVL $90.3M
Type Privacy
Chains Ethereum, Arbitrum, Binance, Polygon
View on DeFiLlama ↗
Control — tentative green Ability to exit — tentative orange Autonomy — green Open Access — green Verifiability — tentative green Control Exit Autonomy Open Access Verifiable
Control criteria
Upgradeability Upgradeable Bug bounty — Governance forum governance.railgun.org Docs docs.railgun.org
About

Railgun lets users shield ERC20/ERC721 assets into an on-chain zero-knowledge privacy system and later spend, transfer, interact with DeFi, or unshield through transact. The core user actions are shield and transact, with private balances represented by encrypted notes in a shared Merkle tree and SNARK-verified spends. Optional broadcasters can relay private transactions for UX/privacy, but the SDK and contracts expose direct contract-interaction paths.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 44 addresses on file · 1 run Submit run ↗
  • Verifiability Unverified Submit run ↗
  • Control ✓ 4/4 models agree AI-only weak green — weak consensus margin Submit run ↗
  • Ability to exit ✓ 4/4 models agree AI-only weak orange — weak consensus margin Submit run ↗
  • Autonomy ✓ 4/4 models agree AI-only 4/4 with chat share link Submit run ↗
  • Open Access ✓ 4/4 models agree AI-only 4/4 with chat share link Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative
    Open source + 9 audits

    Protocol publishes a GitHub repository and has at least one audit on record. This is a coarse Phase-0 signal only: auditor reputation, scope, and post-audit review coverage are not yet weighted.

    Run your own prompt Submit run ↗
  2. Control tentative 4/4 models agree AI-only 4/4 with chat share link
    Upgrades route exclusively through staked-RAIL on-chain governance; uncontested fast path from callVote to executable is 7 days, with no multisig admin and no unilateral emergency override.
    Verdict

    Choosing green because the live on-chain reads show every upgrade and pause path terminating at the Voting contract via the Delegator, with EXECUTION_START_OFFSET = 7 days (604,800 s) — meeting the rubric's 'T1 reachable with uncontested-fast-path delay ≥7 days through active on-chain governance' anchor. The red steel-man (capture by 2 M RAIL) is the inherent risk of any token-governed protocol, not a feature of Railgun's design; the orange steel-man (just-at-bar, unverified distribution) is genuine but the protocol clears the timelock standard and there is no multisig shortcut that would otherwise force orange.

    Steelman argument
    Steelman argument All privileged write paths (upgrade, pause, fee, treasury, blocklist, verification key) require an on-chain proposal that cannot reach the executor until ≥7 days after callVote, weighted by staked RAIL with a 2 M-vote quorum, with no multisig admin, no EOA owner, and no unilateral emergency override.
    Evidence (7)
    C1
    Railgun proxy router 0xFA70…FA4b9 (PausableUpgradableProxy) reports owner() = Delegator 0xB6d5…fB53B; the Delegator reports owner() = Voting (Governor) 0xc480…A3CC at block 25086004–25086006. No EOA or multisig in the chain.
    C2
    Upgradeability: the router is a custom PausableUpgradableProxy whose write surface (upgrade(address), pause(), unpause(), transferOwnership, changeFee, changeTreasury, addToBlocklist, setVerificationKey) is owner-gated; owner is the Delegator, whose owner is the Voting contract. Implementation pointer is live at 0xB4F2…D89b (verified, ABI source: etherscan) — the value differs from the address_book's older 0x3216… entry, evidence the proxy has been upgraded through governance.
    C3
    Execution path: createProposal → 30-day sponsorship window (PROPOSAL_SPONSOR_THRESHOLD = 5e23 = 500,000 RAIL) → callVote → 2d review (VOTING_START_OFFSET = 172,800) → 3d yes/no vote (VOTING_YAY_END_OFFSET = 432,000) → 1d veto-only (VOTING_NAY_END_OFFSET = 518,400) → execution window opens at voteCallTime + EXECUTION_START_OFFSET = 604,800 s = 7 days and closes at EXECUTION_END_OFFSET = 1,209,600 s = 14 days. Uncontested fast-path delay from callVote to executable: 7 days. Executor: Voting.executeProposal which calls Delegator.callContract, which calls the target (proxy).
    C4
    No multisig found in the upgrade path. There is no Safe, no proxy_admin EOA, no emergency council, and no separate guardian role on the Ethereum router. The address_book proxy_admin entry 0x4f8e…65c8 is not the proxy's owner per the live owner() read (owner is the Delegator).
    C5
    Governance reads (block 25086006): QUORUM = 2e24 = 2,000,000 RAIL minimum 'yes' votes; PROPOSAL_SPONSOR_THRESHOLD = 5e23 = 500,000 RAIL; SPONSOR_WINDOW = 30 days; SPONSOR_LOCKOUT_TIME = 7 days; voting offsets are time-denominated (seconds), not block-denominated. STAKING_CONTRACT = 0xEE6A…Ee20 (staked-RAIL is the voting weight). Documentation corroborates: 2 M quorum, 500 k sponsorship, 2 d review + 3 d yes/no + 1 d veto + 1 d buffer + 7 d execution window.
    C6
    No separate emergency-pause or guardian role distinct from governance. pause() and unpause() on the proxy are owner-gated → reachable only via the same 7-day governance path.
    C7
    Highest reachable tier on the fast path is T1: upgrade(address) on the PausableUpgradableProxy can replace the implementation contract for the fund-custody router, and pause() can halt shield/transact/unshield flows. Reachable only through staked-RAIL governance with ≥7-day timelock between callVote and execution.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-built-by-xai url ↗ GPT-5.5 Pro url ↗ View raw submissions ↗
  3. Ability to exit tentative 4/4 models agree AI-only 4/4 with chat share link
    Exit (unshield) is permissionless and directly callable on-chain, but the proxy's pause() — reachable only through the 7-day on-chain governance vote — has no time cap and gates all user flows including claims.
    Verdict

    Choosing orange because pause is indefinite (no auto-expiry, no time cap in the ABI) AND it gates the exit flow, but it is actuated only by the same 7-day on-chain governance pipeline as upgrades — never by an EOA, multisig, or guardian. The red steel-man would force red if a unilateral admin or short-quorum multisig held the pause; here the actor is staked-RAIL governance with a ≥7-day delay, which is the orange criterion.

    Steelman argument
    Steelman argument Pause is indefinite but is reachable only through a 7-day token-weighted vote with 2 M-RAIL quorum, not via any unilateral admin or multisig — matching the rubric's 'orange = indefinite pause is reachable only through governance vote (not unilateral admin action)'.
    Evidence (7)
    E1
    User-facing exit/transact functions on the router proxy 0xFA70…FA4b9 are transact(...) and shield(...) (and the fallback dispatch into the implementation). Unshielding is performed inside transact via the unshieldPreimage/UnshieldType field of the Transaction struct, with an Unshield(address,(uint8,address,uint256),uint256,uint256) event recording the recipient and amount. There is no separate two-step requestWithdrawal / claim pattern — exit is single-step, on-chain, and permissionless when not paused.
    E2
    All user write functions (shield, transact) flow through the PausableUpgradableProxy's fallback dispatch. The proxy contract defines explicit pause()/unpause() functions that disable that dispatch — when paused, both shield and transact (which contains unshield) revert. There is no distinct exit-only function that bypasses pause.
    E3
    Pause role: pause()/unpause() on the proxy are owner-gated; owner is the Delegator 0xB6d5…fB53B, whose owner is the Voting contract 0xc480…A3CC. Pause is therefore reachable only by an on-chain proposal completing the ≥7-day governance pipeline. There is no maximum pause duration encoded in the ABI; ProxyPause/ProxyUnpause events show pause is a binary state, not auto-expiring.
    E4
    No separate emergency-pause path exists distinct from the slow governance route. There is no guardian multisig, no time-capped emergency role, and no gate-seal committee on the Ethereum router; the only pause actor is the same governance executor that performs upgrades.
    E5
    Queued redemption: not applicable — unshielding is single-tx finalization within transact, not a request-and-claim queue. There is no daily withdrawal cap or per-block throttle visible in the ABI.
    E6
    No forced-exit / escape-hatch / permissionless emergency-exit mechanism. Pause is binary and is the only failure mode; there is no fallback that lets users withdraw if governance pauses indefinitely.
    E7
    transact and shield are public, non-payable functions on the verified proxy implementation and are directly callable from any EVM client (Etherscan write tab, ethers/web3, the RAILGUN SDK, or third-party wallets like Railway Wallet). No frontend dependency for exit; the SDK and multiple wallets are documented in the Railgun ecosystem.
    Why is this consensus tentative?
    • weak consensus margin

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-built-by-xai url ↗ GPT-5.5 Pro url ↗ View raw submissions ↗
  4. Autonomy green 4/4 models agree AI-only 4/4 with chat share link
    Self-contained zk-SNARK shield/unshield system with no oracle, no bridge, no off-chain reporter committee, and no keeper-liveness dependency; impacted TVS under any single external-dependency failure is effectively <1%.
    Verdict

    Choosing green because the inspected ABI and docs show no external-dependency surface in the user-funds flow: no oracle reads, no cross-chain message bus carrying TVL, no committee finalizing withdrawals, no keeper required for solvency. Impacted TVS under any single external dependency failure is effectively <1% (essentially zero — there are no qualifying external dependencies). The red steel-man is a control-slice risk (governance-mutable verifying key) re-cast as autonomy, which the slice explicitly excludes; the orange steel-man (precompile/trusted-setup) is base-chain substrate.

    Steelman argument
    Steelman argument No oracles, no bridges, no committees, no keepers required for solvency, no nested collateral. The shield/unshield math is self-contained and verified on-chain via the BN254 precompile; external failures cannot cause loss of principal.
    Evidence (9)
    A1
    External contract calls in the verified router/implementation ABI: none of price-oracle, AMM-pool, lending-pool, or yield-wrapper character. The contract reads/writes only its own internal Merkle-tree state, the ERC-20s being shielded, and a verifying-key registry for SNARK verification. Grep targets (latestAnswer, getPrice, chainlink, pyth, redstone) return no method on the merged ABI.
    A2
    No off-chain reporter committee. There is no exit-bus, no oracle-poster set, no fraud-prover, no DAO-selected validator set acting as a protocol reporter. Verifying keys are governance-set via setVerificationKey, not committee-reported per round.
    A3
    Bridge dependencies: Ethereum L1 deployment has no bridge in its critical path. Arbitrum L2 deployment uses the L1Sender (0x20Fa…3bD5) → L2Executor (0xc480…A3CC) pattern documented for cross-layer governance only — it carries governance messages from Ethereum to Arbitrum, not user funds. Polygon and BSC have their own independent governance and tokens; they are not dependent on Ethereum for fund custody.
    A4
    No nested collateral / restaking chain. Railgun wraps user-deposited ERC-20s 1:1 into Merkle-commitment notes; there is no receipt-of-receipt structure, no slashing power at any level, and no rebasing/yield mechanism that propagates third-party failure into Railgun's accounting.
    A5
    Fork lineage: not stated in any fetched source; the protocol is documented as an original zk-SNARK construction. No finding to record.
    A6
    Fallback mechanisms: the protocol exposes snarkSafetyVector / checkSafetyVectors and a tokenBlocklist as on-chain safety surfaces; these are LIVE and enforcing on-chain (governance can add/remove blocked tokens and safety vectors via the same 7-day pipeline). They are admin-style guards, not external-dependency fallbacks, because there are no external dependencies that need fallbacks.
    A7
    Sequencer/L1-liveness dependency beyond substrate: none. Railgun is not its own appchain; on each chain it inherits that chain's substrate. The Ethereum deployment depends only on Ethereum L1; the Arbitrum/Polygon/BSC deployments depend only on those chains' substrates. A7 does not fire.
    A8
    Keeper / relayer liveness: Railgun's relayer network (used to forward shielded transactions while paying gas in shielded tokens for user privacy) is PERMISSIONLESS and OPTIONAL — a user can submit transact() directly from any wallet without a relayer. If all relayers disappear, users lose the privacy convenience of fee-paying-in-shielded-tokens, but neither principal nor unclaimed yield is at risk and exits remain callable directly. Failure mode is graceful.
    A9
    Governance-mutable external dependency surface: setVerificationKey can replace the SNARK verifying key (a self-internal dependency, not an external one); addToBlocklist/removeFromBlocklist controls which ERC-20s are shieldable. Neither swaps in a new external oracle, bridge, or third-party vault. The router does not reference an upgradable router/registry that would let governance silently introduce a new external contract into the user-funds flow. A9 does not fire in its scope-limited form (admin upgrade authority is a CONTROL-slice concern, captured there).
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-built-by-xai url ↗ GPT-5.5 Pro url ↗ View raw submissions ↗
  5. Open Access green 4/4 models agree AI-only 4/4 with chat share link
    shield/transact/unshield have no whitelist, no KYC, and no operator-approval gate; the protocol is reachable through a published SDK and multiple independent wallet apps (Railway, others) without the Railgun publisher's frontend.
    Verdict

    Choosing green because (a) both core user actions (shield via shield(...) and exit via transact(...) with unshieldPreimage) are caller-unrestricted on the verified implementation, and (b) at least one independent A3b path exists (Railway Wallet as a separately-operated frontend, plus the RAILGUN SDK as a published developer library). Per the slice's default-grade guidance, frontend ToS and publisher-side enforcement are reported as context and do not block green when contracts are permissionless and an independent path exists. tokenBlocklist is a token-asset gate, not a user-admission gate, and does not affect this grade.

    Steelman argument
    Steelman argument Contracts are fully permissionless on shield/transact/unshield with no caller-side whitelist, no KYC, no on-chain user blocklist, and no off-chain operator gate; an independent wallet (Railway) and an SDK both exist as separate publisher paths, satisfying the A3b independent-path test.
    Evidence (7)
    A1
    No whitelist/allowlist/onlyRole/onlyKYC modifier on user-facing entry points. shield(ShieldRequest[]) and transact(Transaction[]) on the proxy implementation 0xB4F2…D89b have no caller restriction — anyone holding the underlying ERC-20 (and a valid SNARK proof for transact) can call them.
    A2
    No off-chain operator approval is required for admission. Relayers may optionally forward a transact() to provide gas abstraction and metadata privacy, but the function admits a self-submitted call from any EOA. There is no privileged poster, sequencer, or gated relayer set.
    A3
    Frontend restrictions: did not retrieve verbatim ToS text from railgun.org in this run (the fetched landing page returned only metadata tags), so A3-passive vs A3-active classification is left to A6 below. Even if the official frontend imposes geo-blocking or ToS clauses, those are publisher-side and not contract-level.
    A3b
    Independent access paths exist: (i) the Railway Wallet (independent mobile wallet developed by a separate entity, reachable on iOS/Android) integrates Railgun for end-users without using a Railgun-operated frontend; (ii) the RAILGUN SDK / engine packages (referenced in docs as the developer entry point) let any developer interact with the contracts directly; (iii) docs explicitly state 'Independent wallet providers can use the RAILGUN protocol' and link to a list of wallet providers. Any of these constitutes a separate publisher path.
    A4
    Sanctions/compliance tooling at the contract level: the router contains a tokenBlocklist(address) mapping with addToBlocklist/removeFromBlocklist admin calls — this is a TOKEN-level filter (which ERC-20s can be shielded), not a USER blocklist. There is no addr→bool blocklist over wallets, no OFAC/Chainalysis oracle wired into shield/transact.
    A5
    Read vs write: all view methods on the router/implementation are public-callable (read-permissionless); the state-mutating user functions (shield, transact) are also unrestricted at the caller level. Admin write methods (changeFee, addToBlocklist, etc.) are owner-only and that ownership chain is the Delegator → Voting contract.
    A6
    ToS / Legal clauses: did not extract verbatim ToS text from railgun.org in this run — the landing page fetch returned only OpenGraph meta-tags, not the body content. ToS posture is therefore recorded in unknowns rather than asserted.
    Sources claude-opus-4-7 url ↗ gpt-5.5-thinking url ↗ grok-built-by-xai url ↗ GPT-5.5 Pro url ↗ View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Railgun has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 48addresses
  • 8verified source
  • 4proxies

TVL adapter pinned at 683d369. Sourcecode fetched 2026-05-06. Control fetched 2026-05-14.

arbitrumPausableUpgradableProxy0xfa70…a4b9TVL + disc✓proxy—router
Arbitrumother (delegator)0xbb7d…ccfadiscovery————
Arbitrumother (implementation)0x5eb6…5877discovery————
Arbitrumother (L1Sender)0x20fa…3bd5discovery————
Arbitrumother (L2Executor)0xc480…a3ccdiscovery————
Arbitrumother (treasuryImplementation)0x39f3…80c1discovery————
Arbitrumproxy_admin0xb00a…d527discovery————
Arbitrumtreasury (treasuryProxy)0x3b37…bfc8discovery———treasury
BinanceBscScan search surfaced a BNB Chain address labelled Railgun: Relay.0x8b7b…1e22discovery————
Binancegovernor (voting)0xc3f2…ac88discovery———governance
Binanceother (delegator)0x4a75…bae7discovery————
Binanceother (getters)0xc7ff…6968discovery————
Binanceother (governorRewardsImplementation)0xae4b…af16discovery————
Binanceother (governorRewardsProxy)0xa7a9…b1f8discovery————
Binanceother (implementation)0x2c4f…a293discovery————
Binanceother (staking)0x753f…41dcdiscovery————
Binanceother (treasuryImplementation)0x1a73…c757discovery————
Binanceproxy_admin0x3bb3…c5d2discovery————
Binancerouter (proxy relay)0x5901…8a10discovery———router
Binancetoken (RAILBSC)0x3f84…737fdiscovery———token
Binancetreasury (treasuryProxy)0xdca0…4094discovery———treasury
bscPausableUpgradableProxy0x5901…8a10TVL✓proxy——
bscRailTokenFixedSupply0x3f84…737fTVL✓———
ethereumPausableUpgradableProxy0xfa70…a4b9TVL + disc✓proxy——
ethereumRailToken0xe76c…a33dTVL + disc✓——token
ethereumStaking0xee6a…ee20TVL + disc✓———
Ethereumgovernor (voting)0xc480…a3ccdiscovery———governance
Ethereumother (delegator)0xb6d5…b53bdiscovery————
Ethereumother (getters)0xe902…eb0ediscovery————
Ethereumother (governorRewardsImplementation)0xaf51…c42bdiscovery————
Ethereumother (governorRewardsProxy)0xa027…c86fdiscovery————
Ethereumother (implementation)0x3216…e13bdiscovery————
Ethereumother (treasuryImplementation)0xa092…f255discovery————
Ethereumproxy_admin0x4f8e…65c8discovery————
Ethereumtreasury (treasuryProxy)0xe8a8…ff40discovery———treasury
polygonPausableUpgradableProxy0x19b6…8c71TVL + disc✓proxy—router
polygonRailTokenFixedSupply0x92a9…714fTVL + disc✓——token
Polygongovernor (voting)0xc3f2…ac88discovery———governance
Polygonother (delegator)0x5f67…83a7discovery————
Polygonother (getters)0x0819…6400discovery————
Polygonother (governorRewardsImplementation)0x2e01…e32ddiscovery————
Polygonother (governorRewardsProxy)0x25f7…bf52discovery————
Polygonother (implementation)0xa375…e9f7discovery————
Polygonother (staking)0x9ac2…ddc1discovery————
Polygonother (treasuryImplementation)0x1a73…c757discovery————
PolygonPolygonScan search surfaced a Railgun-related deployer-labelled address.0x76eb…4624discovery———factory
Polygonproxy_admin0x3c53…5c3adiscovery————
Polygontreasury (treasuryProxy)0xdca0…4094discovery———treasury

Protocol Info

Links

[defillama] Source: DeFiLlama [:] Source: DEFI@home quorum
Website
https://railgun.org
Twitter
@railgun_project
GitHub
5 repositories
Docs
https://docs.railgun.org/wiki/learn/integrating-railgun/railgun-sdks
Governance forum
https://governance.railgun.org

Security

[:] Source: DEFI@home quorum
Audits
6 audits
Bug bounty
unknown
Security contact
unknown

Technical

[:] Source: DEFI@home quorum
Voting token
RAIL Ethereum: 0xe76c6c83af64e4c60245d8c7de953df673a7a33d
Deployed contracts
https://docs.railgun.org/wiki/learn/helpful-links
Upgradeability
Upgradeable

Provenance

[defillama] Source: DeFiLlama
Review status
listed
Updated
2026-06-01 11:27 UTC