Skip to main content

Production limitations and roadmap

Warning: This is a proof of concept. It has not been audited and must not be used to secure real assets.

Outstanding items before this stack is production-ready, sorted by category. This list is deliberately exhaustive — integrators should understand the current state in full.

Security​

LimitationDetail
Unaudited codeNo formal security audit has been performed on any component: Stylus verifier, Solidity validator module, or off-chain tooling.
RC crate dependencyThe ml-dsa crate is v0.1.0-rc.7. API and behavior may change before a stable release. Pin the version; any upgrade requires re-validation against NIST ACVP vectors.
Stylus SDK pre-1.0Known issues include testing-framework segfaults with mappings (#261) and cross-contract return data loss (Nitro #4114). An OpenZeppelin audit found 2 Critical and 2 High issues in the SDK in August 2024.
Off-chain key custodyKey custody is not in scope for the validator stack. Integrators are responsible for their own custody story.

Cost​

LimitationDetail
50× signature size vs ECDSAML-DSA-65 signatures are 3,309 bytes vs 65 bytes. On Arbitrum, L1 data posting is the dominant expense at $2–8 per transaction vs cents for ECDSA.
3.7× UserOp gas vs ECDSARoughly half is cryptographic verification (~374K gas) and half is ERC-7579 / Kernel routing.

See Gas and cost model for the full breakdown.

Operational​

LimitationDetail
Stylus reactivation requiredContracts auto-deactivate after 365 days or after ArbOS upgrades. No monitoring or alerting is built in. Schedule reactivation explicitly.
Immutable verifier addressUpgrading the Stylus verifier requires deploying a new Solidity module and migrating all accounts. There is no proxy pattern.
Single ML-DSA implementationThe verifier wraps the ml-dsa crate (RustCrypto) only. A second-source implementation for cross-checking is not feasible within current Stylus compressed size limits (~3.3 KB headroom).

Missing features​

LimitationDetail
No key rotationThe stored public key can only be changed by uninstalling and reinstalling the module.
No sender allowlistisValidSignatureWithSender accepts any sender. Per-account allowlisting is on the roadmap.
No signature aggregationSingle-validator, non-aggregated path only. Bundler-side UserOp batching is a future direction.
No paymaster integrationThe demo flow requires pre-funded smart accounts.
Demo wallet is not production-readyThe demo Snap requires MetaMask Flask (developer build) and relies on manual browser seed entry for signing. It is for verification, not consumer use.

Testing gaps​

LimitationDetail
Bundler compatibility untested beyond AltoNot tested with Pimlico hosted, Alchemy, Stackup, or other production bundlers. ERC-7562 storage access rules need validation against each.
No Sepolia or mainnet deploymentAll measurements are from a local devnode with zero L1 fees. Gas cost figures in this documentation are projections from Arbitrum mainnet pricing.
Mock-based Solidity testsUnit tests stub Stylus calls with vm.mockCall. Integration testing requires a running devnode and is exercised by E2E scripts, not by forge test.

Roadmap​

The path to production, in expected order:

  1. Sepolia deployment — deploy the verifier and module to Arbitrum Sepolia, measure real L1 data cost, and republish the gas table.
  2. Bundler compatibility matrix — submit reference UserOps to each major bundler; document what works, what needs configuration, and what doesn't.
  3. Audit — both the Stylus verifier (cryptographic correctness and Stylus integration) and the Solidity module (ERC-7579 conformance, storage access, ERC-1271 surface).
  4. Key rotation — a safe rotation flow that does not require uninstalling the module.
  5. Sender allowlist — configurable per account on isValidSignatureWithSender.
  6. Production monitoring — Stylus deactivation alerts, gas regression alerts, scheduled on-chain test transactions.
  7. Mainnet deployment — only after items 1–6 are complete and the audit is closed.