Risks & Operations

What can go wrong when trading or running a bot on Vision, and how to avoid it

Risks & Operations

This page lists ways to lose money. It is the most honest page in these docs. Read it. Then decide.

Vision is a sealed parimutuel prediction market. You bet real USDC against other participants. Everything below is what can go wrong — and in a zero-sum game, going wrong is the default state for roughly half of all participants, always.

---

Capital Risks

You Can Lose Your Entire Deposit

Vision is zero-sum minus fees. For every dollar someone wins, someone else loses. This is not a warning — it is arithmetic. If your predictions are consistently wrong, your balance trends to zero. There is no stop-loss mechanism. Your stakePerTick is deducted every tick, relentlessly, indifferent to your conviction or your strategy or your reasons for being here.

House Edge

The protocol takes 0.05% of profits. Even a perfectly calibrated coin flip loses money over time. The house always wins — not dramatically, not unfairly, but with the quiet patience of entropy. You need a win rate of essentially 50% to break even. The edge is barely there — which is the point.

Break-even win rate ≈ 50.025% (with 0.05% fee on profits)

Stake Burn Rate

Every tick, you risk stakePerTick USDC. The clock does not pause. Your deposit depletes at this rate if you lose every tick:

Ticks until depleted = deposit / stakePerTick
Example: 100 USDC deposit, 1 USDC/tick stake → 100 ticks max
At 5-minute ticks = ~8 hours of runway
At 1-hour ticks = ~4 days of runway

A high stakePerTick relative to your deposit burns capital in hours. Start with a ratio of 1:50 or lower until you have validated your strategy. The market will wait — it has destroyed more patient people than you.

Correlated Markets

Many markets in a batch move together — BTC and ETH, for instance, share the same moods. Bet all-UP on a correlated batch and watch the market drop: you lose on nearly every market simultaneously. Diversification is harder than it looks when everything is secretly the same thing.

---

Operational Risks

The ways your machine can fail you. These are not market risks — these are engineering risks. The cruelest ones, because they mean losing money not because you were wrong about the future, but because your code had a bug.

Bitmap Not Submitted

If your bot joins a batch but fails to submit the bitmap to oracles, your predictions are never revealed. You lose stakePerTick per tick — punished not for bad predictions but for having no predictions at all. This is the single most common bot failure.

Fix: Always verify {"accepted": true}. Implement retries with a 3-second backoff.

Indexer Lag

After calling joinBatch() on-chain, the oracle needs ~6 seconds to detect the PlayerJoined event. Submitting the bitmap too early returns 404: Player not found.

Fix: Wait at least 6 seconds between joinBatch() and POST /vision/bitmap. Retry on 404.

Nonce Collisions

If your bot sends multiple transactions in rapid succession without tracking nonces, they can collide and revert.

Fix: Track nonces locally: nonce = w3.eth.get_transaction_count(address) before each transaction, increment manually for back-to-back sends.

RPC Failures

The Arbitrum RPC endpoint can be temporarily unreachable. A single failed transaction mid-cycle can leave the bot in an inconsistent state (e.g., USDC approved but batch not joined).

Fix: Wrap every on-chain call in retry logic. On restart, check on-chain state (has the bot already joined this batch?) before re-attempting.

Gas Exhaustion

Every on-chain action costs gas. Run out of ETH and every transaction fails silently — the machine, suddenly mute, unable to express even the wrong opinion.

Fix: Monitor ETH balance alongside USDC. Set an alert at 0.01 ETH.

BLS Proof Unavailability

Claiming rewards requires a BLS-signed proof from oracle nodes. If oracles are down, the claim fails. Your money is there. You simply cannot touch it.

Fix: Retry with exponential backoff. Unclaimed rewards do not expire. They wait — which is more than can be said for most things that owe you money.

---

Smart Contract Risks

The risks that live in the code itself. These are the rarest and the most terrifying, because they are the ones no one can fix after the fact.

Immutable Code

Vision contracts are deployed on Arbitrum. Bugs in the contract logic could result in loss of funds. Code, unlike people, does not learn from its mistakes — it repeats them, deterministically, forever.

Solvency

The contract includes a solvency check (InsolventPayout) — if the USDC balance cannot cover a payout, the claim reverts. Under normal operation this should never happen. “Should never happen” is the preamble to every catastrophe.

BLS Key Rotation

If the oracle set rotates BLS keys, old proofs become invalid. Claim rewards promptly. Do not let profits accumulate in a system you do not control — that is not savings, it is faith.

---

Pre-Flight Checklist

Run through this before starting a bot or placing your first bet. Preparation will not save you from the market. It will save you from yourself.

1. Fund Your Wallet

   Your wallet needs both USDC (for deposits) and ETH (for gas) on Arbitrum.

   • USDC: At least 2x your planned deposit (to cover joins + additional deposits)
   • ETH: At least 0.05 ETH for gas (dozens of transactions)
2. Verify Contract Addresses

   Double-check the Vision contract address and USDC address match the contract reference. Do not trust addresses from unofficial sources.

3. Test with Minimum Stake

   Join one batch with the minimum: 0.1 USDC deposit, 0.1 USDC stake. Verify the full cycle works (join → submit bitmap → claim) before scaling up.

4. Validate Bitmap Submission

   After joinBatch(), confirm you receive {"accepted": true} from the bitmap endpoint. Check the oracle API: GET /vision/balance/{batch_id}/{your_address} — it should show your position.

5. Set Exposure Limits

   Decide your max total exposure across all batches. The reference bot uses max_exposure and max_batches config fields for this.

6. Monitor Claim Cycle

   Verify that claimRewards() succeeds at least once before increasing your deposit. A successful claim proves the full pipeline (predictions → resolution → BLS proofs → on-chain payout) is working.

---

Bot Operator Checklist

For running a bot in production. The machine does not care about its own survival. You must care on its behalf.

1. Process Management

   Run the bot under a process manager (systemd, pm2, supervisor). It should auto-restart on crash.

2. Log & Alert

   Log every join, bitmap submission, claim, and error. Set up alerts for: repeated failures, low USDC balance, low ETH balance, bitmap rejection.

3. Balance Monitoring

   Track your USDC balance over time. If it’s steadily declining, your strategy has no edge. Stop the bot and re-evaluate.

4. State Recovery on Restart

   On restart, the bot should check which batches it has already joined on-chain (via getPosition()) and rebuild its joined_batches set. Never duplicate-join.

5. Periodic Withdrawal

   Don’t let profits accumulate indefinitely in the contract. Withdraw periodically to your own wallet. Claimed rewards are yours; unclaimed rewards depend on oracle availability.

6. Strategy Validation

   Backtest your strategy against historical tick data before running live. Use POST /vision/backtest from the strategies guide to simulate.

7. Multiple Oracle Endpoints

   Submit your bitmap to all known oracle nodes, not just one. If one oracle is down, the others still store your bitmap. The bot needs at least 2/3 of oracles to accept the bitmap for it to participate in resolution.

---

Common Failure Modes & Recovery

Failure	Symptom	Recovery
Bitmap not submitted	Balance decreases every tick despite good predictions	Check bitmap submission logs, verify accepted: true
Submitted too early	404 Player not found	Wait 6+ seconds after joinBatch(), retry
Wrong bitmap hash	400 Hash mismatch	Recompute: keccak256(bitmap_bytes) must match joinBatch(bitmapHash)
Nonce collision	Transaction reverts	Track nonces locally, don’t rely solely on get_transaction_count
Out of gas (ETH)	All txns fail	Top up ETH, set balance alert at 0.01 ETH
Out of USDC	InsufficientDeposit revert	Top up USDC, reduce max_batches
Oracle unreachable	Bitmap submission timeout	Retry other oracle URLs, check network
Stale BLS proof	InvalidBLSSignature on claim	Re-fetch proof from oracle API
Bot already registered	BotAlreadyRegistered revert	Skip registration (idempotent, catch error)
Batch paused	BatchPaused revert	Filter out paused batches in poll loop

---

Risk Summary

Everything that can go wrong, ranked by how much it will cost you. Read the severity column. If you can live with all of them simultaneously, proceed.

Risk	Severity	Mitigation
Losing deposit	High	Start small, validate strategy with backtests
Fee drag	Low	Maintain win rate above 50.025%
Bitmap failure	High	Verify accepted: true, retry logic
RPC downtime	Medium	Retry with backoff, check state on restart
Gas exhaustion	Medium	Monitor ETH balance, set alerts
Contract bug	Low	Limited to deposited amount
BLS proof delay	Low	Retries; unclaimed rewards don’t expire