Sigma Wallet deploys a vault that only moves money once enough co-owners agree. You hold the keys; the contract holds the rule. This guide covers what you'll actually click, and exactly which address can do what.
Three co-owners, three independent keys. All three approve before a transfer executes, no single address, including the one that deployed the vault, can move funds alone.
| Fixed | Configurable | |
|---|---|---|
| Deployment fee | 1× base price | 2× base price (every payment mode: fixed USDT, custom token, promo) |
| Thresholds & delays | Locked forever at deployment; nobody, ever, can change them | Co-owners can later change 6 parameters (transfer/replace thresholds, execute delays, approval windows) by proposing, waiting out the delay, then executing. Needs n−1 approvals |
| Switch later? | No. The choice is made once at deployment and is permanent for the life of the vault. | |
| Best for | A vault whose rules should never move, even if co-owners change their minds | A team whose approval policy may need to evolve (e.g. loosening a delay once trust is established) |
Interactive
Slide the co-owner count. Readout uses Fixed defaults (transfer = all, replace = n−1). Configurable can later change thresholds with an n−1 vote.
Transfer needs {transfer}/{n} approvals; once met, any co-owner can execute.
Replace needs {replace}/{n} approvals; after the wait window, any co-owner can execute.
Interactive
Pick a type. The choice is made once at deployment and cannot be flipped later.
Sigma Wallet has gone through three Factory contracts. Vaults already deployed keep working exactly as before; only the ability to create new ones changes.
| Generation | New deployments? | Rules |
|---|---|---|
| V2: current | ✅ Active | Fixed/Configurable V4 vaults as above, plus a guardian-gated bytecode allowlist (a stolen Factory-owner key alone cannot push unreviewed vault code) and an owner dashboard that only opens in a short signed window. |
| V2: superseded 2026-11-07 | ❌ Suspended | Same V4 Fixed/Configurable vault rules, but the Factory itself had no bytecode allowlist. Replaced by the current V2 Factory; vaults it already deployed are unaffected. |
| V3: legacy | ❌ Suspended | The original 3-fixed-slot model described in the rest of this guide: unanimous (3-of-3) approval to transfer, but only Co-Owner 1 can execute even after all 3 approve; 2-of-3 to replace a co-owner. |
Open "Your Vaults" in the app: each vault shows which generation deployed it, and the page compares rules whenever your own vaults span more than one generation.
These five places keep money for different failures. The useful question is which failure you are willing to accept. A Ledger can also be one co-owner key inside a Sigma vault or a Safe — that is combining tools, not replacing them.
| One-key software wallet | Ledger (hardware) | Exchange account | Sigma vault | Safe | |
|---|---|---|---|---|---|
| Who holds the coins | That software wallet | Addresses derived from the seed shown on the device | The exchange | Your vault contract | Your Safe contract |
| Where the private key lives | Phone / browser / extension | Secure Element on the device (when genuine and untampered) | Exchange custody systems | No single vault private key — co-owner keys hold the votes | No single Safe private key — owners hold the votes |
| Who can move funds | That one key, immediately | Whoever controls the device PIN and the recovery phrase | The exchange, under its rules | Enough co-owners vote; any current co-owner then chooses the recipient | Enough owners sign one specific transaction |
| One stolen key / one bad signature | Can empty the wallet | Device alone is hard to drain without PIN; a stolen or leaked recovery phrase empties everything | Can empty the account; the exchange can also freeze it | One co-owner alone cannot open a transfer round | One owner alone cannot pass a threshold above 1 |
| Phishing / malicious website | High — software sees the full signing request | Lower if you verify amount and address on the device screen; still fatal if you approve a bad tx or type the seed into a fake site | Account takeover / fake support | A fake site cannot forge co-owner votes on-chain; it can still trick a co-owner into voting | Same: threshold still needed; a tricked owner can still sign a bad tx |
| Physical / supply-chain risk | Device theft + unlocked phone | Real risk. Oct 2026: some devices sold via reseller CryptoBilis were found with a hidden implant that read the recovery phrase from the screen during setup and sent it over a mobile network. Ledger says its Secure Element and servers were not breached. Genuine Check cannot detect an added implant when the original chip is intact. Buy only from authorized channels; never initialize a suspect unit; if already used, move funds under a newly generated phrase | Company seizure, hack, insolvency | No device to implant; risk is co-owner keys and governance | No device to implant; risk is owner keys, modules, and migration |
| If a person disappears | Only the seed opens it | Only the recovery phrase (or a backup you already made) opens it | Support may restore login; withdrawal still depends on the company | Others can replace one missing co-owner. Two or more missing keys freeze the vault | Remaining owners can often replace a signer; extra recovery needs a module |
| What the funds can do | Anything that wallet can sign | Whatever apps you connect; the device only signs what you approve on-screen | Buy, sell, withdraw listed assets | ERC-20 transfer, POL withdraw, replace co-owner; Configurable can change six settings. No arbitrary contract calls | Other contracts, batches, many chains |
| Offline / air-gap style signing | Usually no | Yes — keys stay on device; host only proposes the tx | No | Votes are on-chain from each co-owner wallet (can be a Ledger) | Owners can sign with hardware wallets |
| Recovery options | Seed backup only | Recovery phrase; optional Ledger Recover is a separate trust trade-off (shares encrypted shards) | Password reset / KYC | Replace one missing co-owner with n−1; no social-recovery module | Owner replacement + optional modules |
| Single point of failure | The seed / that device | The recovery phrase (and supply-chain trust when you first set up) | The company | Losing ≥2 co-owner keys; Fixed holdout who blocks replace | Threshold owners acting together; modules / upgrade path |
| Best fit | Small daily spend, high convenience | Personal cold-ish custody when you trust the purchase channel | Trading and on/off ramps | Small team shared Polygon vault with narrow rules | Large treasury, DeFi, multi-chain |
| Outside review | No product audit applies | Mature vendor; incident history includes reseller implant case (2026) and past Connect Kit / Recover debates | Company controls, not your contract | No completed third-party audit | Years in production, multiple professional audits |
transferToken or withdrawNative. The vault has no function that pulls coins out of a personal wallet.The line-by-line check is Vault security review, 10 November 2026. It is an internal review, not a third-party audit.
| Dimension | Sigma Wallet | Safe{Wallet} | Note |
|---|---|---|---|
| Co-owner replacement | ✅ n−1 votes + 24 h wait + 72 h execute window, built in | ⚠️ A normal multisig transaction; runs as soon as threshold is met unless you add a module | Sigma |
| Who can execute | ✅ Any co-owner | ✅ Any owner | Tie |
| Attack surface | ✅ Single-purpose, immutable, no arbitrary external calls | ⚠️ Audited core, but modules / delegatecall add complexity | Sigma |
| Licensing & anti-clone | ✅ Needs the Factory-minted, non-transferable license NFT | ❌ None | Sigma |
| Upgrade path | ✅ Deployed vault has no proxy and no upgrade; Factory changes only affect future vaults | ⚠️ Proxy account; threshold owners can migrate the logic. Safe the company cannot upgrade it alone | Trade-off |
| Signature coordination | ⚠️ Every vote is on-chain (costs gas), no service dependency | ✅ Off-chain signatures (saves gas), usually via Safe’s transaction service | Trade-off |
| How soon a transfer can run | ⚠️ Transfer wait defaults to 0; the vote does not name the recipient; a passed round expires after 24 h | ⚠️ Executable immediately by default; delays need optional modules | Trade-off |
| Cost model | Deployment charges a license fee (promo codes supported) | Deployment costs only chain gas | Different |
| Audit & track record | ⚠️ Newer; no completed third-party audit yet | ✅ Years in production, multiple professional audits | You may prefer Safe |
| Ecosystem & chains | ❌ Polygon-focused, one purpose-built dApp, no backend | ✅ Multi-chain, wide dApp support | You may prefer Safe |
| What it can do | ❌ Only transfer / withdraw POL / replace / (Configurable) change params | ✅ Arbitrary contract calls and batched transactions | You may prefer Safe |
| Threshold flexibility | ⚠️ 3–5 co-owners; Fixed locks transfer threshold; Configurable can change 6 params | ✅ Any m-of-n | You may prefer Safe |
| Extensibility & recovery | ❌ No modules; losing ≥2 co-owner keys locks the vault | ✅ Modules (allowances, social recovery…), which also widen the risk surface | You may prefer Safe |
Safe is a general-purpose smart account; Sigma is a purpose-built vault. The “Note” column is a preference hint for that row, not an overall security verdict — Sigma has not yet had a third-party audit.
Fixed wallets: thresholds are locked at deployment (transfer = all co-owners, replace = n−1). Configurable wallets: co-owners can later change thresholds/delays by the same propose → wait → execute, n−1 flow.
All 3 must approve, but only Co-Owner 1 can press execute, even after unanimous approval.
Once the threshold is met, whichever co-owner gets there first can execute. No single-slot bottleneck.
The V3 Factory is permanently suspended — nobody can deploy a new V3 vault today — but V3 vaults deployed years ago still work exactly as before. If yours is one of them, it runs on the original 3-fixed-slot model:
Once a wallet is loaded, you can view:
Fixed vaults: a transfer needs every co-owner's approval. Configurable vaults: co-owners set the threshold themselves and can change it later. If nobody executes before the approval window (TTL) expires, approvals reset to zero — see "Troubleshooting" below.
Token transfers require ALL 3 co-owners to approve (set Status 2), and can only be executed by Co-Owner 1 (Primary Controller) — a restriction unique to V3. V4 has no such bottleneck.
If nobody executes before the countdown ends, the window expires and every approval resets to zero.
If any co-owner changes their mind before execution:
Co-owner replacements need 2 of 3 co-owners to approve (set Status 3) — similar in spirit to V4's n−1 threshold. The difference is V3 used the status system instead of propose/approve records, but the replacement itself could be executed by any co-owner.
fee() returns right now, shown at the top of the page in POL. It is not a number baked into this guide. The Factory owner can change it from Admin → Mailbox.Interactive
Click the three steps in order. The license NFT is minted to the vault contract, not your personal wallet, and it cannot move funds.
Token is not transferable. Transfer and approve both fail; ownership stays on the vault.NFT required. Without this license, transfers and replacements will not run.Anyone can read it. No key, no signature, just an address to ask about.
The real owner key signs first to open a short 20-minute window before the data becomes readable at all.
Changes on-chain state. Needs a real signature from the actual key holder, no exceptions, every time.
| Category | Examples | Who can actually use it |
|---|---|---|
| Fully public | Deployment pricing, a vault's co-owners, vote counts and thresholds, promo-code validity if you already know the code, how many vaults an address has deployed | Anyone, by design. Multisig governance state is meant to be checkable by any co-owner or outside observer. |
| Owner-only, signed window | Promo code usage details, the full list of every vault ever deployed (owner monitor dashboard) | Only the real owner key, and only for a short window (20 minutes) that that key must open first with an actual signed transaction. Knowing the owner's address is not enough; watching it in a wallet or copying it elsewhere grants nothing. |
| Signature required, every time | Any setting change, fee withdrawal, ownership transfer, vault-bytecode upgrade, co-owner approvals/replacements on a vault | Only whoever holds the actual private key. These change on-chain state, and a state-changing transaction can never be sent without a real signature, on any EVM chain. |
Click a question to expand it. Grounded in the actual deployed contracts, not generic boilerplate, if something here ever looks wrong, trust the contract source over this page and tell us.
A non-custodial multi-signature vault platform on Polygon. You deploy your own vault contract; Sigma never holds a key that can move your funds.
Fixed locks its thresholds/delays forever at deployment. Configurable costs 2× and lets co-owners later change 6 parameters via an n−1 propose→wait→execute vote. Neither can be converted into the other after deployment.
No. The choice is permanent the moment the deployment transaction confirms. There is no migration path, you'd deploy a new vault and move funds over yourself.
3 to 5 for V4 vaults. The legacy V3 model (no longer deployable) was fixed at exactly 3.
Polygon Mainnet only for real funds. The team also tests against Polygon Amoy and Ethereum Sepolia testnets; those aren't for real value.
No, it's a responsive web app. You connect from your phone's browser or a wallet app's built-in browser, same contracts either way.
Just a Web3 wallet (MetaMask, 1inch, Trust, Coinbase Wallet, etc.). The site itself needs no install.
Anything supporting WalletConnect v2 or browser injection (EIP-6963), plus Coinbase Wallet directly. WalletConnect v1-only wallets are not supported, that protocol was deprecated.
Whatever the Factory's current price is, check the Deploy page, it's read live from the contract and can change. Configurable always costs exactly 2× whatever Fixed costs that day.
Fixed USDT, a custom ERC-20 token, a promotion (with or without a code), or Free, whichever the Factory owner currently has active. Only one mode is live at a time.
If one is active and you know it, it unlocks a discounted (or free) price for that one deployment. Codes aren't publicly listable unless the owner has made them viewable, knowing the code is how you prove you're meant to use it.
No, the contract tracks per-address usage and blocks a repeat use of the same code by the same deployer address.
No. Fees are non-refundable and on-chain transactions are irreversible, this is stated plainly in the Terms you accept before deploying.
It's a soulbound (non-transferable) license NFT minted directly to the vault contract itself, not to your wallet. The vault checks it owns this exact NFT before any governance action will run, it's a tamper check, not a collectible.
No, every transfer function on it is hardcoded to revert. It's deliberately permanent.
EVM transactions are atomic, either the whole deployment (contract + NFT mint + payment) succeeds, or none of it does and your gas is the only cost. There's no "half-deployed" state.
Only one Factory is ever active for new deployments at a time, check "Wallet Versions & Rules at a Glance" above for which generation is currently live.
No, the V3 Factory is permanently suspended. Every new deployment today is V4 (Fixed or Configurable).
Each co-owner calls approve once per "round." Once enough votes are in (the vault's threshold, all co-owners for Fixed by default), a countdown opens during which any co-owner can execute.
Yes, as long as the threshold hasn't been met yet. Once it has, the round moves to its execute window and can no longer be individually revoked.
The approval window (TTL) expires, the round resets, and everyone needs to approve again from scratch.
On V4, any co-owner, there's no special slot. (The old V3 model restricted execution to co-owner slot 0 even after unanimous approval; that bottleneck is V3-only and doesn't exist in V4.)
Fixed in the source code, yes, but the 2 real V3 vaults already deployed on mainnet run the old, unfixed bytecode permanently, contracts can't be hot-patched. V4 never had this issue.
n−1 co-owners vote to approve a specific replacement (slot + new address). After the threshold is met there is a 24-hour wait, then any co-owner can execute inside the 72-hour window.
On Operate, select the vault and scroll to the “Replace a Co-Owner” section (or tap REPLACE CO-OWNER under “All Actions”). If no proposal exists yet there is no standalone Approve button: the first co-owner clicks “Propose & approve replacement”, which counts as their approval vote; after that, the others see an “Approve this replacement” button in the same section. At n−1 approvals plus a 24-hour cooling-off, anyone executes from the same section. This is a separate round from the transfer approvals at the top of the page.
Yes, nothing stops the remaining co-owners (or you, voting alongside them) from replacing your own slot with a new address.
The remaining co-owners can vote to replace that slot with a new address, same as any other replacement.
There is no recovery mechanism. The vault and everything in it is permanently locked. Back up seed phrases seriously.
Yes, 6 parameters (transfer/replace thresholds, execute delays, approval TTLs) via propose → wait out the delay → execute, needing n−1 approval each time.
Yes, on purpose, calling proposeParamChange on a Fixed vault always reverts with "Fixed wallet." That's a feature, not a bug.
No, n−1, same as replacing a co-owner. Full unanimity is only required for the transfer threshold by default (and even that is itself a changeable parameter on Configurable vaults).
Yes, by design, multisig governance state (co-owners, vote counts, thresholds) is fully public on every vault, so any co-owner or outsider can audit it independently.
For the two things the Factory actually restricts (promo-code details, the full deployment list), no, both require a real signed transaction from that exact key to open a short time window first. Knowing the address alone gets you nothing.
A second, independent key that alone can allowlist new vault bytecode hashes. The owner can't reassign it and the two never share a key, so a single compromised owner key can't push malicious vault code by itself.
A pattern where a real signed transaction (not just an address match) opens a short, time-limited period during which a sensitive view function becomes readable. It's the strongest protection actually achievable on a public chain for a read call.
Yes, on PolygonScan, verification means the published source matches the deployed bytecode exactly; it is not itself a security audit.
They could change pricing, promo codes, or propose a new vault bytecode, but the guardian still has to separately approve any new bytecode hash first, and existing deployed vaults are unaffected regardless (vault governance lives on the vault, not the Factory).
No. Your vault contract holds them. Nobody, including the maintainers, has a key that can move funds out of a vault they aren't a co-owner of.
No. This is explicit in the Risk Disclaimer: you use this at your own risk, with no recovery process offered by the maintainers.
Check the project's own published security docs for current audit status, don't assume either way from this guide alone.
Per the published Privacy Policy: no backend database, no analytics/telemetry, the site itself is static and doesn't track you. Your wallet provider and any RPC endpoint you use have their own separate policies.
The TTL window passed before anyone executed. Someone needs to call the reset/cleanup step, then all required co-owners approve again from scratch.
The vault's required NFT is missing or doesn't match, shouldn't happen under normal use since it's non-transferable. If you see this on a vault you believe is legitimate, stop and get help rather than retrying blindly.
Only relevant on the 2 real old V3 vaults. On those, only the slot-0 address can execute transfers even after everyone approves, see the "slot 0 only" FAQ above.
Switch your wallet to Polygon Mainnet (chain ID 137), this app doesn't support real-fund actions on any other network.
Use "Estimate Gas" before sending, and make sure you hold enough POL. The app pads its gas limit well above the estimate on purpose, to reduce failed-transaction risk.
Common on mobile browsers: switching to your wallet app to approve can suspend the site's background connection to the WalletConnect relay. Try the wallet app's own built-in browser instead of your phone's regular browser, it avoids the app-switch entirely.
It may have hit its usage cap, been deactivated, or you may have already used it from this same address, codes are strictly one-use per deployer address.
Some public RPC endpoints report this incorrectly for transactions that actually confirmed. Check the real status directly on PolygonScan with your transaction hash before assuming it failed.
Make sure you're connected with the same address you deployed from (or a co-owner address), on Polygon Mainnet, and try "Refresh", the ledger re-scans on-chain history each time rather than caching it.
That page only unlocks for the current Factory owner, its guardian, or a nominated pending owner, connecting any other address will always show this.
Try reloading the page fully before reconnecting. If it still fails, note the exact error text, it usually points to a wallet-specific signing quirk rather than anything on your end.
The monitor dashboard is an owner-only feature, guardian only controls the bytecode allowlist panel. Seeing "access denied" there with a guardian key is expected, not a bug.
Pricing is set live by the Factory owner and can change at any time, always trust what the Deploy page shows right now over anything remembered from a previous visit or screenshot.
It is not in the top header. Open it from the site footer ("Feedback") or from Leave a message. The User Guide link in the header is this document.
Only a vault deployer or a current co-owner of that vault. The contract checks both against the Factory directory and the vault's co-owner list. Anyone else reverts.
Whatever the live fee() on FeedbackMailbox is, shown at the top of the page in POL. It is not a fixed number in this guide. The owner can change it from Admin → Mailbox. The amount you send must match exactly.
A secret note is encrypted to the admin mailbox key in your browser; only the admin passphrase can decrypt it. Public feedback is queued for approval unless immediate publish is on. Rejected plaintext is never written in the clear.
The Factory owner has not called setMailbox yet. Secret notes and approve-first public notes cannot be sent until that key exists on-chain. Immediate-publish public notes can still be sent if that mode is on.
After you confirm in the wallet, the page waits for the on-chain receipt and then shows a Polygonscan link. Until that receipt succeeds, treat it as unconfirmed. The published wall only lists notes the admin has approved (or that went out under immediate publish).
Sigma Wallet v1.0.0 · Last updated November 2026