FAQ

What happens if I let my window expire?

If nobody flips you before your active window ends, you keep everything already credited to you from the fee stream up to that point. That part is never at risk. But if someone later takes the slot from you after your window has expired (an "expiry takeover"), you forfeit 100% of the ETH you originally paid and 100% of your token deposit. You get nothing back on either leg. This is by design, not a bug. See overview.md and security.md for exactly why the mechanic works this way.

Can the team take my funds?

Your already-credited balances (the ETH, WETH, and $TOKEN owed to you) are withdrawn by you, and only you, through a permissionless claim function. Nothing about that path involves the team. Separately, the protocol does retain certain administrative capabilities typical of an early-stage, non-multisig-controlled contract at this stage of the project, described at a high level in security.md. If that trust model matters to your decision to participate, read that page before you do.

How do I claim what I've earned?

Call the contract's claim function. It pays out your entire credited ETH, WETH, and $TOKEN balance in one transaction, whenever you want, whether or not you still hold the slot. See contracts.md for the exact function signature and behavior.

Why did someone flip me instantly after I bought?

If it happened within the immunity period right after your own purchase, it shouldn't have been possible at all: that's exactly what the immunity period exists to prevent, and the contract will reject a flip attempted during it. If it happened right after immunity ended, someone was simply watching the chain and had a transaction ready to submit the moment they were able to. There is no way to prevent a fast, correctly-priced challenge once immunity has ended. That responsiveness is the whole mechanic. See provably-fair.md for why gas bribes don't help anyone jump ahead of you on this chain specifically.

What is the keeper for?

The keeper is an automated bot that calls the contract's permissionless fee-collection function at useful moments (right before your window ends, right after, and periodically while you hold the slot) so your credited balance stays fresh without you or anyone else needing to trigger it manually. It has no special privileges: the function it calls is open to literally anyone, it cannot move your funds, and it cannot change who holds the slot. See security.md for the full trust model.

Do I have to wait for the keeper to get credited for my fees?

No. Anyone, including you, can call the same permissionless function yourself at any time. The keeper is a convenience, not a dependency.

What's the difference between being flipped and an expiry takeover?

Being flipped means someone displaces you while your window is still active: you get a 75% ETH refund, and the person who flipped you gets a 50% rebate on your token deposit. An expiry takeover means your window had already ended before anyone displaced you: you get 0% back on either leg, and the person who takes over gets no rebate either. See overview.md for the full breakdown of both paths.

Is there any randomness involved in who wins a flip?

No. There is no random number generator anywhere in this system. Whoever's transaction lands first at a price the contract currently accepts takes the slot, full stop. See provably-fair.md.

Can I lose more than my entry cost and deposit?

The most you can lose in a single occupancy is the ETH you paid for the slot plus the token deposit you put up, and only if you are later displaced via an expiry takeover. If you're flipped while your window is still active, you get 75% of your ETH back. Either way, you also keep whatever fees were credited to you during your window regardless of how the occupancy ends.

Why does the price and deposit go up after every flip?

The escalation step makes each successive flip cost more than the last, which is also what funds the 75% ETH refund and 50% token rebate on a genuine in-window flip. The incoming buyer always pays strictly more than the outgoing holder did, and that difference is what makes the refund solvent. See provably-fair.md for the exact formula.

What happens to the token deposits that never get refunded?

They are absorbed and retained by the protocol rather than returned to the displaced holder, on both settlement paths (only the rebated share, on a genuine in-window flip, goes to the incoming buyer instead; see overview.md). They are never burned.

Can the price or window duration change after I've bought in?

Certain economic parameters can be adjusted by the protocol over time, but any parameter change only ever affects the next claim's terms going forward. It cannot reach back and retroactively change what you already paid, what you're already owed, or the terms of an occupancy that's already settled. Always check the current live values via the view functions in contracts.md rather than assuming a number you saw earlier still applies.

Is the contract upgradeable? Could the rules change under me mid-game?

The contract itself has no proxy or upgrade mechanism: its core logic cannot be swapped out after deployment. Some configuration values are adjustable, as noted above, but the fundamental mechanic (pull-based claims, the fixed 75% refund share, the deterministic price/decay formulas) is fixed in the deployed code. See security.md for the full picture.

Where can I verify any of this myself?

Everywhere. The whole point of provably-fair.md is that you don't have to take anyone's word for any outcome: every price, deposit, refund, and rebate is a formula you can recompute yourself against public chain data.