Question 1

If the curator is so good, why does he need my money?

Accepted Answer

Same reason a hedge fund manager raises capital: scale, not skill. A trader with a verified edge generates 10x more PnL on $100k than on $10k. Same win rate, bigger size. The capital amplifies the edge, it doesn't create it. Difference with SuperStrat: every settlement, every NAV, every fee mint is on-chain. You audit the track record before depositing. No Bloomberg, no quarterly letter, no marketing. Just a Polygonscan address.

Question 2

What actually stops the curator from stealing my deposit?

Accepted Answer

Straight answer: on V2.5, no smart-contract mechanism stops the curator from sending trader-wallet funds elsewhere once they've been funded. We pick this trade-off intentionally — see the Hater FAQ below. What the vault DOES guarantee: pending deposits sit in a segregated silo the curator cannot touch (smart-contract enforced). Curator can only deploy a vault if they're on factory.allowedCreators, which we control off-chain. Every fund movement is on-chain and publicly traceable from the moment it leaves the vault, through the trader wallet, into Polymarket's deposit wallet. The protection model: vetted curators with a reputation to protect, an allowlist that gates entry, and real-time transparency that makes silent theft impossible. If a curator absconds, depositors see it instantly on Polygonscan, and the curator's on-chain history is permanently marked.

Question 3

What stops the curator from trading memecoins or some random shitcoin instead of Polymarket?

Accepted Answer

Nothing on-chain. Once the curator funds their trader wallet via fundTrader, the USDC.e is in a curator-controlled EOA — they could in principle send it to Uniswap, a perp DEX, anywhere. We acknowledge this and chose the trade-off intentionally. Why we accept it: Polymarket V2 only recognizes its own ERC-1967 deposit wallets in the polymarket.com UI. A vault-controlled Safe (the V2.3 architecture we built and deployed mainnet at factory 0x444Eb264…) was invisible to polymarket.com, so curators couldn't trade. The trader-EOA model is the price of working with the real Polymarket today. What replaces on-chain enforcement: the curator allowlist (only vetted addresses get there), on-chain transparency (the oracle bot watches transfers from the trader wallet and surfaces anomalies), and reputation cost. If you find a curator's behavior off-strategy, you redeem at the next epoch.

Question 4

Why USDC.e and not real USDC? USDC.e is deprecated everywhere else.

Accepted Answer

Because Polymarket V2 settles in USDC.e on Polygon PoS. The Polymarket V2 collateral plumbing (CollateralOnramp/Offramp wrapping USDC.e into pUSD) is hardcoded to USDC.e. If we accepted native USDC, we'd have to bridge or swap it before any trade — adding gas, slippage, and a failure mode. USDC.e is not deprecated on Polygon. Circle continues to honor 1:1 redemption. The 'deprecated' framing comes from Circle pushing native USDC across chains via CCTP — useful for cross-chain treasuries, irrelevant for a Polygon-native trading vault. If you only hold native USDC, swap to USDC.e via any Polygon DEX (Uniswap, Quickswap) before depositing. The slippage is negligible.

Question 5

What is pUSD, and why does it appear in the flow if I deposited USDC.e?

Accepted Answer

pUSD is Polymarket V2's internal collateral token, minted 1:1 by their CollateralOnramp from USDC.e. It exists for one reason: Polymarket's exchange contracts (CtfExchangeV2, NegRiskCtfExchangeV2) only accept pUSD as collateral. Polymarket handles this wrapping transparently. When the curator deposits USDC.e on polymarket.com, Polymarket's Onramp wraps it to pUSD before trades. At offramp time, pUSD unwraps back to USDC.e. You as a depositor never see pUSD. You deposit USDC.e to the vault, you redeem USDC.e from the vault. Why a custom token? Polymarket needed a collateral they could control (mint/burn rules, fee policies, future upgrades) without depending on Circle. Annoying for integrators but rational for their roadmap.

Question 6

The NAV is proposed by an off-chain oracle. So SuperStrat is just centralized DeFi cosplay.

Accepted Answer

Conceded — the NAV proposal is off-chain. There's no honest way around it: pricing thousands of Polymarket CLOB positions in mid-market on-chain at every block is not affordable today. Three on-chain guardrails. (1) Max 20% deviation per proposal from the last settled NAV — coded as NAV_MAX_DEVIATION = 2000 bps. You can't suddenly claim the vault is worth 10x. (2) Proposal valid only 4 hours, then expires. Stale data can't be silently consumed. (3) The curator must call settle(expectedNAV) where expectedNAV must equal proposedNAV — re-confirms intent and catches oracle bugs. Residual risk: if oracle + curator collude on a faked NAV (within the 20% band), they can extract fees from depositors. Mitigation is role separation in production: oracle is an automated bot reading public Polymarket CLOB, curator is the human trader, two different wallets. V2 will replace the oracle with a ZK proof of CLOB mid-prices — for now, role separation is the answer.

Question 7

Why can't I withdraw instantly like on Aave?

Accepted Answer

Aave's instant withdraw works because Aave is a money market: deposits and borrows are continuously priced by oracle, withdraws come from a pool of idle liquidity, and the borrowers' positions back the system. SuperStrat is a trading vault: 90% of capital can be in open Polymarket positions with no instant market price. Instant withdrawal in a trading vault breaks two ways. First, front-running — someone with knowledge of an imminent good NAV deposits a second before, then redeems a second after, extracting gain they didn't contribute to. Second, fire sales — if everyone redeems at once, the curator must close positions at any price. ERC-7540 (the standard SuperStrat implements) batches everyone's deposits and redemptions into the same epoch settling at the same NAV in the same block. No one front-runs anyone. And the curator picks the settlement moment when positions are liquid. If settlement stalls more than 7 days, you can cancel and exit.

Question 8

Why are vault creators whitelisted? This sounds like permissioned DeFi cosplay.

Accepted Answer

Because SuperStrat isn't trying to be Uniswap-for-trading-vaults. It's a curated marketplace, like Morpho's Curators, Yearn's strategists, or Lagoon's vault deployers. Quality-controlled curator selection is the product. Permissionless vault creation creates a spam surface — fake vaults imitating real traders' names, malicious curators draining their own vaults, vaults marketed with fabricated track records. V2.5's trust model (curator EOA controls trader wallet) makes vetting non-negotiable. We chose moderation instead. The allowedCreators check is the only gating. Once a curator is whitelisted, the on-chain rules apply identically — same factory, same vault implementation, same custody guarantees. SuperStrat the platform can't censor an existing vault. We can only deny new creations.

Question 9

20% performance fee is robbery. I could just stake USDC on Aave.

Accepted Answer

Aave on Polygon yields roughly 2-5% APY in USDC stable. SuperStrat-backed Polymarket strategies target double-digit returns by taking directional risk on prediction markets. Different products, different risk profiles, comparing them is comparing T-bills to equity. The 20% is on profits only, above the all-time high-water mark. Vault loses 10% and recovers? Zero fee on the recovery. Vault flat for a year? Zero fee. No management fee, no entry fee, no exit fee — only performance fee, only on new gains, only above HWM. That's the institutional hedge fund standard, automated. If you don't want trading exposure, Aave is the right call. SuperStrat exists for capital that wants Polymarket exposure without trading it themselves.

Question 10

Why is the high-water mark global instead of per-depositor? I'm subsidizing other people's gains.

Accepted Answer

Conceded — a depositor entering after a drawdown does benefit from the curator's recovery without paying fees on it. That's the trade-off. Why we chose it: per-depositor watermarks create the 're-deposit reset' attack. A depositor experiencing losses redeems and re-deposits 1 USDC.e to reset their watermark, effectively dodging fees on the recovery. Global HWM is immune — there's nothing personal to reset. Global HWM is also the industry standard (hedge funds, mutual funds, structured funds). The fee is charged at the vault level, not per individual, and the math is fair across decades of finance literature. Practical effect: if you enter mid-drawdown and the vault recovers fully, you got 'free' performance to the previous high. If you enter mid-rally and it keeps going, you pay fees on every dollar gained from that point. Net-neutral on average across the depositor pool.

Question 11

What if your smart contract has a bug and I lose everything?

Accepted Answer

Honest answer: smart contract risk is non-zero. Every DeFi protocol carries it. Here's what we did to minimize it. Built on OpenZeppelin v5.5.0 (ERC-4626, AccessControlEnumerable, Pausable, ReentrancyGuard, ERC1155Holder, SafeERC20). These libraries secure billions in TVL across DeFi. V2.5 strips ~30% of V2.3's surface area: no Guard, no Safe, ~800 lines of custom Solidity in PolyVaultV21 + ~70 in FeeSplitterV2. Smaller surface = smaller attack surface. solidity-reviewer PASS, security-auditor SECURE (with one acknowledged MEDIUM: curator can drain trader-wallet funds — intentional, documented, see the Hater FAQ). Architectural inspiration: Lagoon (audited 6× by Nethermind, $134M+ TVL across 70+ vaults). Our implementation is our own and we are commissioning an independent audit before broad public marketing. Emergency paths if a bug surfaces: admin can pause the vault. Pending deposits remain recoverable directly by depositors via emergencyClaimPendingDeposit — not sent to admin. Strategy funds go to admin for manual distribution. Both paths are tested and on-chain. Residual risk: the audit isn't published yet. Until it is, treat early deposits as exploratory size, not your savings.

Question 12

What happens if the curator just stops settling?

Accepted Answer

After 7 days without settle(), anyone with a pending deposit or redeem can call cancelPendingDeposit / cancelPendingRedeem and recover their funds directly from the contract. No permission needed. If you're a shareholder (not pending), the admin can replace the curator via submitRoleChange — 48-hour timelock, so you see the swap coming and can exit if you don't trust the replacement. Worst case: admin pauses the vault. emergencyWithdraw drains strategy funds to admin for manual depositor reimbursement; emergencyClaim paths let depositors with pending requests reclaim independently. Curators who ghost destroy their on-chain reputation permanently. Every settlement (and every absence of settlement) is recorded forever in epochSettledNAV.

Question 13

What if YOU (the platform admin) pause the vault and run away with the funds?

Accepted Answer

Conceded — the admin has real powers: pause, emergencyWithdraw, role changes, setTraderWallet. So let's be exact about what they can and can't do. Can: pause the vault, drain strategy funds (idle USDC.e minus pending silo) to themselves, replace curator/oracle (48h timelock), set the trader wallet once at vault setup, emergencyRecallFromTrader when paused. Cannot: touch the pending deposit silo. When the vault is paused, any depositor with a pending request can directly call emergencyClaimPendingDeposit / emergencyClaimPendingRedeem and reclaim from the contract. Admin has no path to those funds. The segregation is enforced by the contract, not by promise. Cannot: upgrade the contract. PolyVaultV21 is deployed via Clones (minimal proxy) pointing at an immutable implementation. There is no upgrade path. If we wanted to change behavior, we'd have to deploy a new factory and migrate vaults — depositors would have a clear exit window via requestRedeem. Cannot: rotate the trader wallet. setTraderWallet is one-shot — once set, the trader EOA is fixed for the life of the vault. Admin can't silently swap it to drain funds. Residual risk: shareholders (post-settlement, not pending) take a loss if admin emergency-withdraws. Mitigation in production: admin role transitioned to a multisig (transferOwnership is 2-step), then to a timelock contract. That's the path we are on.

Question 14

Could a whale watching the mempool front-run the settlement transaction?

Accepted Answer

No. This is the central guarantee of ERC-7540 epoch settlement. Imagine the whale sees a pending settle() transaction with a favorable NAV. They try to insert a deposit before it lands. The deposit is queued as a request — it doesn't mint shares immediately. By the time the next block settles, their request is part of the SAME epoch as the settle, and they receive shares at the same NAV as everyone else who deposited in that window. They captured nothing. The only way to gain from foresight is to deposit in an earlier epoch (already done, can't be retroactive) or to predict the NAV trajectory of a future epoch (allowed and rewarded — that's what good investing is).

Question 15

What if Polymarket shuts down or gets regulated out of the US?

Accepted Answer

Open Polymarket positions resolve based on the market's defined criteria, regardless of Polymarket's corporate state. The curator claims winnings on polymarket.com, offramps to USDC.e, recalls to the vault, settles, depositors redeem. The vault depends on Polymarket's smart contracts being callable, not on Polymarket the company being healthy. If polymarket.com the UI is geo-blocked, the curator can still interact with CtfExchangeV2 / NegRiskCtfExchangeV2 directly (CLOB API with POLY_1271 signing). Slightly less convenient, still functional. Their deposit wallet stays callable. Long-term existential risk: yes. If Polymarket V2 contracts change in incompatible ways, curators would have to migrate to a new architecture. If Polymarket dies and stops resolving markets, capital stuck in open positions stays stuck — that's a Polymarket risk, not a SuperStrat-specific risk. SuperStrat doesn't custody anything that depends on our company being alive. Even if we disappear tomorrow, every vault keeps functioning: curator settles, depositors claim. The site goes down, the contracts don't.

Question 16

You don't have on-chain custody during trades. The curator can run off with the money.

Accepted Answer

Confirmed. Once the curator funds the trader wallet, the USDC.e is in their EOA — they could in principle send it to any address. No smart contract stops them. The alternative was a Safe + Guard architecture (V2.3, deployed mainnet at factory 0x444Eb264… on Polygon). Polymarket V2's UI doesn't recognize Safes — only their own ERC-1967 deposit wallets at factory 0x00000000000Fb5C9ADea0298D729A0CB3823Cc07. Our Safes were invisible to polymarket.com. Curators couldn't actually trade. V2.5 replaces on-chain custody with: a vetted curator allowlist (factory.allowedCreators), real-time on-chain transparency (every fund movement publicly traceable), and reputation cost. We make the trade-off explicit. See the trust-model statement in the docs.

Question 17

Why not just use Safe + Guard like V1?

Accepted Answer

We did. V2.3 shipped to Polygon mainnet — factory at 0x444Eb264a4de9386e23d334441d2EA78c8Df3871, fully audited, with PolyStratGuardV2 enforcing custody. The architecture was sound. It failed empirically. Polymarket V2 deprecated the legacy Safe-based deposit-wallet factory (0xaacFeEa…3541b) and migrated to ERC-1967 proxies at their new factory 0x00000000000Fb5C9ADea0298D729A0CB3823Cc07, signed with POLY_1271. Their docs confirm: polymarket.com's UI only sees deposit wallets from that factory. Safes don't appear, can't trade. V2.5 is what's left after admitting the V1/V2.3 model is incompatible with the real Polymarket today. The V2.3 vaults still live under /vaults/legacy — funds recoverable, but not tradable.

Question 18

What stops a malicious curator from draining the vault?

Accepted Answer

Off-chain: factory.allowedCreators. We vet curators before allowlisting them. If a curator misbehaves on one vault, we revoke them across all future vaults. The whitelist is the gatekeeper. On-chain: nothing prevents the geometric drain documented as audit MEDIUM-1. A curator can fundTrader, send the trader wallet's USDC.e elsewhere, repeat. The reserveFloor in fundTrader sets a per-call denominator-based floor, but it does NOT bound aggregate losses. We documented this in the spec and in vault NatSpec. Mitigation: reputation, transparency, and the oracle's mark-to-market NAV at settlement. A draining curator produces an immediately observable NAV drop. settle() honors that lower NAV; depositors are paid out proportionally on whatever remains. V2.6 roadmap includes a curator-bond + slashing module (see spec §11).

Question 19

Why ERC-4626 + ERC-7540 epoch settlement instead of synchronous deposits and withdrawals?

Accepted Answer

Because Polymarket positions can't be liquidated on demand — markets resolve on their own timeline, and orderbook depth varies. Synchronous redemptions would force the curator to dump positions at fire-sale prices the moment anyone wanted out. Epoch settlement (Lagoon-style, $134M+ TVL in production) batches all deposits and redeems into the same block at the same NAV. No front-running, no fire sales, no special privilege. The curator picks the settlement moment when positions are liquid. The 7-day cancel guard is the escape valve if they stop settling.

Question 20

Why pUSD and not native USDC?

Accepted Answer

Because Polymarket V2 routes all trading collateral through pUSD — their 1:1 wrap of USDC.e (Polygon's bridged USDC at 0x2791…). CtfExchangeV2 and NegRiskCtfExchangeV2 only accept pUSD as collateral. Depositors interact in USDC.e: deposit USDC.e, redeem USDC.e. The curator handles the wrap on polymarket.com via Polymarket's Onramp (USDC.e → pUSD) and Offramp (pUSD → USDC.e). pUSD never appears in the vault flow. We didn't pick pUSD. Polymarket did. We work with their architecture as-is.

Question 21

Why is the curator the same wallet as the admin in your test? That's worse than nothing.

Accepted Answer

That's just the test deploy. Same wallet across all three roles (admin/curator/oracle) is a convenience for the validation playbook, not a recommendation. Production guidance: admin = a separate cold wallet or multisig you control as platform/protocol governance; curator = a fresh EOA used only for this vault's polymarket.com trading; oracle = an automated bot wallet running the NAV proposal script. The contract doesn't enforce role separation — that's an operational best practice. Curators who collapse roles signal less rigor. Depositors should check, and we'll surface role distinctness on the vault detail page.

Question 22

Why not slashing or insurance for curator misbehavior?

Accepted Answer

Roadmap item, V2.6 (see spec §11). The design: curator locks a security bond (e.g., 10% of funded amount). Bond is releasable only after honest settlement; slashable to depositors pro-rata if the oracle detects funds outside the (traderWallet ∪ depositWallet) set at settle time. Bond + slash restores partial crypto-economic security without breaking the polymarket.com UX. We didn't ship it in V2.5 to get the trust-based model production-tested first — bond mechanics are non-trivial and a separate contract. For now: allowlist + reputation only. If you need stronger guarantees, wait for V2.6 or stick with V1 vaults (legacy section).

Question 23

Why is your performance fee minted as vault shares and not paid in stable?

Accepted Answer

The fee is a percentage of vault-level profit above the global high-water mark. Minting it as fresh vault shares to the FeeSplitter at settle dilutes all shareholders evenly — which IS the fee mechanism, no separate transfer needed. Benefits: no USDC.e needs to be liquidated to pay the fee (positions stay open). Fee recipients hold shares that compound with the vault, or redeem at their leisure through the same epoch flow. Same rules as any depositor — no special privilege. Industry standard. Hedge funds, mutual funds, structured products all do it this way. Per-claim USDC.e payouts would be a worse mechanism on every axis.

Question 24

Polymarket can ban the curator's deposit wallet whenever they want. That's a vector you don't control.

Accepted Answer

True. Polymarket controls their UI, their compliance, their deposit-wallet contracts. If they ban a curator's deposit wallet, that vault is stuck — open positions resolve on-chain, but the curator can't open new ones. What we do: the curator can still offramp from a banned deposit wallet (the offramp contract is permissionless once positions resolve). They recall USDC.e to the vault, settle at the residual NAV, depositors redeem. What we don't pretend: SuperStrat doesn't insulate you from Polymarket's policy choices. Polymarket itself is the same risk depositors take when they trust the curator to trade there at all.

Question 25

How is this not just "give your money to some guy" with extra steps?

Accepted Answer

Because the steps are real, observable, and constrain the rest of the experience. What "some guy" can't offer: a public on-chain track record across every settlement and every NAV; pending-deposit isolation that prevents the curator from touching your unsettled USDC.e; ERC-7540 batch settlement so you can never be front-run; a 48-hour timelock on role changes; an emergency-recall path the admin can pull when paused; performance fees calculated and minted by the contract, not by the curator's spreadsheet. What V2.5 explicitly DOES NOT offer: contract-enforced custody once funds are in the trader wallet. We're upfront about that. If you don't trust the curator with funded capital, don't deposit. The vetting is what makes the model work.

Straight answers.

The criticism we get most.

Good. Read the docs.