How Zeit Works
Zeit wraps prediction-market strategies into Perpetual Prediction Vaults (PPVs), so you can own a worldview/strategy as a single ERC‑20 share token.
High‑Level Flow
Vault managers actively trade a portfolio to express a worldview
Managers can buy, sell, hedge, rotate, and rebalance positions before markets resolve — taking profit, cutting risk, or updating exposure as new information arrives.
Strategies can trade across Polymarket and other supported prediction markets/venues as integrations expand.
In short: Polymarket gives you odds on events. Zeit gives you a perpetual strategy token that can trade those events dynamically including exiting before resolution — and keep the worldview alive over time.
Deposits & Withdrawals
Deposits and withdrawals are processed in batches (liquidity events / roll periods). Batching is used to (i) reduce timing-based advantages such as front-running/MEV around liquidity events, (ii) reduce gas costs per participant by aggregating requests, and (iii) avoid forcing large, instantaneous trades into thin orderbooks.
Terms
Epoch / Roll: a processing cycle where queued deposits/withdrawals are settled and accounting is updated.
PPS (price per share): the vault’s share price used to mint/burn PPV shares during a roll.
Pending deposit / pending withdrawal: a request that has been submitted but not yet processed in a roll.
Deposits
Deposits are processed every 24 hours.
Flow
Submit deposit
Users deposit collateral into the vault contract.
The deposit is recorded with a timestamp and/or epoch ID.
Pending state
Until the next roll, the deposit remains pending (not yet converted into PPV shares).
Netting with withdrawals
At the roll, the vault nets deposits against withdrawals where possible.
Example: if withdrawals exist, a portion of them can be funded by incoming deposits, reducing the amount of positions that must be sold to raise collateral.
Mint PPV shares at roll PPS
The vault computes NAV and sets PPS for that roll.
Deposits are converted into shares using the roll PPS:
Shares minted = deposit amount / PPS.
Withdrawals
Withdrawals are processed in batches.
The minimum withdrawal processing interval is typically 24 hours, but the actual interval can be vault-configurable.
This configuration exists because the time required to exit positions can vary by strategy and market liquidity.
Flow
Submit withdrawal
Users submit a withdrawal request specifying the number of PPV shares (or value) to redeem.
Pending state
The request enters a withdrawal queue until the next processing event.
Collateral sourcing
Withdrawals are funded using one or more of the following sources:
Idle collateral already held by the vault.
Netting against deposits in the same roll (incoming deposits cover some outgoing withdrawals).
Position reductions (selling/closing positions to free collateral).
Burn shares and pay out collateral
When processed, the vault burns the corresponding PPV shares and transfers collateral to the withdrawing user.
Automated unwind
Vaults include an unwind mechanism intended to ensure withdrawal requests can be fulfilled:
If collateral is not freed in time by the manager’s normal execution, the system can reduce positions via market sells in batches (split execution) to free collateral while limiting single-trade price impact.
In these cases, execution quality may be worse than a patient unwind (i.e., higher slippage), but the mechanism prioritizes fulfilling queued withdrawals.
NAV calculation (mark-to-market)
The vault maintains a Net Asset Value (NAV) that represents the total value of the vault expressed in its base collateral (currently USDC.e on Polygon).
At a high level:
NAV is the collateral-equivalent value of:
idle collateral held by the vault, plus
the marked-to-market value of all open prediction-market positions,
minus any accrued liabilities (e.g., fees owed, if applicable at that checkpoint).
PPS (price per share) is derived from NAV:
PPS = NAV ÷ total outstanding PPV shares
PPS is the conversion price used when processing deposit/withdraw batches at roll checkpoints.
What “mark-to-market” means here
Prediction-market positions are not valued only at resolution. Instead, they are valued continuously using current market prices.
For each open position, the vault maintains a price estimate based on market data (see below). That price estimate is used to compute the position’s current value in USDC.e terms.
This produces a NAV that changes as:
orderbooks move,
trades execute (position sizes change),
markets resolve (positions settle to payout),
collateral moves in/out due to deposits, withdrawals, and redemptions.
Price sources and real-time updates (Polymarket CLOB)
For Polymarket CLOB markets, the system subscribes to real-time orderbook updates (WebSocket / streaming feeds) and updates marks as the book changes.
This is used to maintain:
the best bid / best ask and depth profile,
recent trades / last-trade updates (if provided),
and an up-to-date view of what prices are realistically executable at size.
The goal is to compute NAV using the most current orderbook state available rather than relying on stale snapshots.
Two NAV views: “paper” vs “impact-aware”
Thin orderbooks are common in prediction markets. A mid-price mark can look good on paper while being difficult to realize if you actually needed to unwind.
For transparency and risk management, valuation is separated into two related concepts:
Paper NAV
“What is the vault worth if I mark positions at a reference price?”
Marks positions at a reference price (often mid or top-of-book based). Ignores depth/impact.
Impact-aware NAV (liquidation NAV)
“What would the vault likely realize if it had to unwind positions now?”
Marks positions using an orderbook-depth-aware estimate (simulated unwind / book-walk) to account for price impact.
Impact-aware NAV is used for operational decisions where realizability matters, especially:
sizing how much USDC.e must be freed for queued withdrawals,
setting roll checkpoint PPS used for mint/burn,
and computing performance fee checkpoints fairly under low liquidity.
Impact-aware NAV is an estimate based on observable depth. Actual realized execution depends on how orders are placed over time.
“Sell now” vs “hold to resolution” (what users should understand)
NAV is a mark-to-market number. It is not the same thing as “what happens at resolution.”
A prediction-market position has two relevant frames:
Sell now (market exit): Your realized value depends on the orderbook (spread + depth + impact). Impact-aware NAV is designed to approximate this in a conservative way.
Hold to resolution (settlement): Positions settle to their payout at resolution (e.g., a winning side pays out; a losing side goes to zero). This avoids orderbook slippage but does not remove outcome risk (you are still exposed until the event resolves).
Because the vault holds a portfolio, it may be optimal to:
hold some positions into resolution,
exit others early (risk reduction, taking profit, rolling to a new market),
or unwind gradually due to liquidity constraints.
This is why the system surfaces mark-to-market NAV while also accounting for execution reality (impact).
NAV breakdown (what’s included)
A practical NAV breakdown is:
Idle collateral (USDC.e)
Marked value of open positions
sum across all markets and tokens, each using the selected mark (paper or impact-aware)
Reserved/allocated collateral
collateral earmarked for redemptions (e.g., moved into the redemption adapter after a withdrawal roll)
Accrued liabilities
e.g., performance fees accrued at a checkpoint (if applicable), protocol fees, or other configured deductions
Valuation cadence: live estimates vs roll checkpoints
NAV/PPS exists in two “modes”:
Live estimate (continuous / near real-time)
Updates as orderbooks update and trades execute.
Used for monitoring, transparency, and risk checks.
Checkpoint PPS (roll-based)
At deposit/withdraw processing events (“rolls”), a PPS is checkpointed for:
minting shares for deposits,
burning shares for withdrawals,
fee checkpoints (e.g., high-water mark performance fee).
This separation allows a vault to provide continuous visibility while still using discrete, auditable pricing points for accounting actions.
Flow diagram
Why this is done
Transparency: users can see how NAV moves with markets, positions, and collateral.
Execution realism: thin orderbooks are accounted for by impact-aware valuation instead of mid-price-only marks.
Lower operational risk: withdrawal sizing and roll pricing are based on a valuation approach that reflects liquidity constraints.
Rebalancing / Rolling
Rebalancing objective
The vault holds a portfolio of prediction market positions that express a strategy (e.g., long/short views across outcomes or probability spreads). Rebalancing adjusts position weights to match the target strategy, risk limits, or to take advantage of new opportunities.
Rolling/resolution handling
When a constituent prediction market resolves, the vault realizes the payout for that market and then re-deploys the freed collateral into new prediction markets to preserve the perpetual nature of the PPV.
Rebalancing typically happens at scheduled epochs or when triggers occur (market resolution, significant drift from target allocation, or a strategy signal).
Mechanism
The vault executes trades (buy/sell positions or enter/exit markets) to move from the current portfolio to the target portfolio. Trades can be executed on-chain against market contracts or via order-routing mechanisms supported by the market infrastructure.
The vault enforces risk and exposure limits during rebalances to avoid over-concentration and to cap the maximum trade size relative to market liquidity.
Execution and Slippage Considerations
Slippage sources
Market impact: executing large trades on thin prediction markets can move prices and increase execution cost.
Liquidity depth: low liquidity increases the expected slippage and may force the vault to execute over multiple blocks/epochs.
Price spread / fees: bid-ask spreads and per-trade fees in the underlying market infrastructure add to execution cost.
Mitigations
Batching and trade slicing: break large trades into smaller child orders executed over multiple epochs or blocks to reduce instantaneous market impact.
Limit orders and price checks: use limit orders, guarded executions, or pre-execution price checks to avoid executing at stale or extreme prices.
Slippage limits: the vault can enforce per-trade slippage tolerance thresholds; trades that would exceed tolerance can be skipped or rescheduled.
Liquidity-aware sizing: cap trade sizes relative to market depth and use multiple markets/contracts where available to disperse execution.
Accounting for slippage
Actual slippage and execution costs are reflected in subsequent NAV calculations; extreme slippage impacts share price and may affect queued deposits/withdrawals.
Operational execution choices trade off immediacy (faster rebalances) versus execution quality (lower slippage and cost). The vault design documents the chosen balance.
What is on-chain vs off-chain?
Zeit uses an on-chain vault as the source of truth, and off-chain services for CLOB execution, pricing/analytics, and reporting/proofs. This split exists because prediction markets (especially CLOB-based ones) require off-chain order flow and because orderbooks can be thin, making impact-aware pricing and staged execution important.
On-chain
On-chain components are the authoritative state of the vault.
Vault contracts (Boring Vaults fork + extensions)
Hold the vault’s collateral (currently USDC.e on Polygon).
Issue and burn PPV ERC‑20 shares.
Record deposit/withdraw requests and their settlement status.
Enforce roll checkpoints (mint/burn windows, accounting updates).
Apply the vault’s fee mechanics at checkpoints (e.g., performance fee with HWM, paid in shares if configured).
Venue settlement / asset ownership
Positions and balances that must be enforceable (ownership of assets, collateral movements, share supply) are finalized on-chain.
Any state that changes NAV in a way that must be auditable (e.g., share mint/burn, collateral allocation for withdrawals) is committed on-chain.
Why this matters
Users can verify balances and share supply directly from on-chain state.
On-chain rules constrain what off-chain actors can do (off-chain systems can submit actions, but the vault enforces what is valid).
Off-chain
Off-chain components are used for execution, computation, and reporting, especially where real-time orderbook interaction is required.
CLOB relayer / execution agent (Polymarket CLOB)
Submits orders to the Polymarket CLOB on behalf of the vault (including cancels/updates).
Tracks fills and execution status and coordinates multi-step actions.
Orderbook observing + price impact engine
Continuously reads orderbook depth and computes impact-aware pricing (“what if we sold now”) rather than relying only on mid-price (“paper”) marks.
Produces inputs used for:
roll PPS/NAV checkpoint calculations,
withdrawal planning (how much USDC.e needs to be freed),
reporting and strategy monitoring.
Execution tools
Implements execution logic that is impractical to run entirely on-chain, such as:
DCA / time-sliced execution
TWAP-style unwinds
staged limit orders / auto-limit style execution
unwind prioritization (e.g., illiquid positions first)
Metadata + proofs + reporting (Arweave)
Generates roll reports and distribution artifacts (e.g., deposit/withdraw allocations for a roll).
Produces proofs/commitments for these distributions and publishes the report data to Arweave for long-term, public availability.
The intent is that third parties can independently review roll inputs/outputs using:
on-chain events (authoritative)
Arweave-published artifacts (reproducible reports / proofs)
Summary (Operational Considerations)
Deposits and withdrawals are typically batched and queued to reduce gas and improve execution quality; they are processed against the NAV at processing epochs.
NAV is mark-to-market using on-chain market prices or oracles and is computed whenever needed to price shares and process user flows.
Rebalancing and rolling occur on market resolution or at scheduled epochs; trades are executed with attention to liquidity and risk constraints.
Execution costs and slippage are real and should be mitigated via slicing, limits, and liquidity-aware sizing; these costs flow through to NAV/share price.
Core state and final actions are on-chain; strategy computation and execution orchestration are frequently off-chain but should be constrained and auditable by on-chain rules.
Last updated