A market that keeps moving
after the close.
TIDE is a time-driven market protocol for a fixed-supply token on Robinhood Chain. It combines spot trading, after-hours opening orders and two-sided price predictions into one deterministic cycle.
Production · TIDE. This page describes the protocol and new-launch model. The app's connected contracts determine the current schedule, fees and limits; a trial token is not the official TIDE release.
The spot market does not simply stop. When the live session closes, TIDE turns the gap before the next session into an explicit market for orders and expectations.
Protocol architecture
TIDE separates trading, scheduling, settlement, positions and rewards into dedicated contracts. The controller acts as the time and settlement coordinator while custody remains isolated in purpose-built components.
TideTokenFixed-supply ERC-20 used by the official TIDE/WETH market.
TideHookControls the official Uniswap v4 pool, enforces the market schedule and maintains the geometric price oracle.
TideLiquidityManagerCreates and holds the protocol liquidity position and collects LP fees.
ProtocolControllerCoordinates the Europe/Madrid market clock, TWAP references, settlement and market outcomes.
OpeningAuctionEngineCollects after-hours orders and computes a uniform opening price that maximizes executable volume.
ParimutuelPredictionVaultTwo user-funded ETH pools with live implied probability, a 5% total-pool fee and pull-based payouts.
LifeboatVaultOptional dual-asset reserve for capped instant execution during Ebb, with non-transferable LP shares.
RewardsDistributorDistributes WETH rewards according to holder balance and holding time.
Flood, Ebb and Slack
The protocol surface is determined by the contract clock. Each phase exposes a different set of actions and produces the input required by the next one.
Users buy and sell TIDE through the official pool. The session produces the closing reference used by the next-open markets.
Users queue opening orders and trade directional positions on whether the next official open will be above or below the previous close.
Eligible opening interest is locked, the auction clears at one price and prediction positions settle from that official opening result.
The scheduling layer is defined in the Europe/Madrid timezone and coordinated by ProtocolController.
One book. One opening price.
After-hours orders do not execute independently against a stale last price. They enter a common opening book and clear together at a uniform price.
- 01Queue
Users submit irrevocable opening orders while after-hours markets are active.
- 02Lock
Eligible buy and sell interest is frozen for the opening event.
- 03Find the clearing price
The engine selects the price that maximizes total executable volume.
- 04Execute uniformly
Every matched opening order receives the same official opening price. Marginal interest can be prorated.
Only the net imbalance needs to interact with the AMM. Claims are pull-based, and custody is separated into the auction vault/executor path.
Price direction without leverage
TIDE exposes a binary market on the next official opening price. Positions express a directional view rather than leveraged spot exposure.
ParimutuelPredictionVault holds one fully collateralized user pool per side. No market maker or protocol seed is required. Each side's share of total committed ETH is shown as its implied probability.
For example, 1 ETH in ABOVE and 2 ETH in BELOW implies 33.3% ABOVE and 66.7% BELOW. If ABOVE wins, its 1 ETH receives 2.85 ETH after the 5% fee.
If the official open exactly equals the previous close, or the auction resolves through an invalid or aborted fallback path, every user receives their original stake back without a fee.
If either pool has no user collateral at settlement, the market is void and every stake is returned. Implied probability reflects committed capital, not an objective forecast.
Instant execution with a shrinking-reserve price
LifeboatVault is an optional, separately capped path for users who do not want to wait for the opening auction. During Ebb it buys or sells TIDE immediately at the previous official close, then applies a dynamic penalty based on the projected depletion of the asset lane being consumed.
The active session snapshots its risk configuration and opening reserves on first use. Later parameter changes cannot reprice that session. Capacity is directional, per-session and per-wallet, so users cannot drain the entire reserve through one route or one account.
Liquidity providers deposit proportional TIDE and ETH during Flood, receive non-transferable lbTIDE shares and can redeem only after the one-session lock. Retained penalty revenue increases the assets backing every outstanding share.
The app reads the configured vault's reserves, penalty curve and limits from the contract. A test deployment is not the official token launch. Always verify the active token and contract addresses before depositing.
Fees flow back to holders
The reward layer distributes WETH using balance × time rather than a single-block snapshot. This rewards persistent exposure to the token instead of transient balance changes around distribution time.
If an epoch has no eligible holders, its reward amount is re-queued instead of becoming trapped.
TIDE token
TideToken is a fixed-supply ERC-20 designed around a single official market.
The final token address can be precomputed with CREATE2 using TideTokenDeployer, allowing the rest of the protocol to be configured before token bytecode is materialized.
Protocol parameters
Uniswap v4 can additionally apply a directional protocol fee. Settlement reads the live fee state and accounts for the composed fee when calculating required input.
Trust and administration
TIDE v1 is not trustless administration. The upgradeable protocol components are controlled by the deployer EOA and there is currently no Safe, timelock or guardian layer.
TideLiquidityManager is UUPS-upgradeable. A verified recovery implementation can be used by the administrator to withdraw or migrate the managed liquidity position.
Auction escrow and parimutuel stakes are distinct from protocol liquidity and treasury funds. Claim, refund and redemption eligibility is determined by the deployed contracts, round status and claim deadlines. Pausing trading does not itself transfer user assets to the administrator.
The contracts should not be deployed with real user funds before an independent security review, and production documentation should disclose administrative capabilities prominently.
Deployment model
The launch controller allows the token, hook and pool to be prepared while trading remains disabled. The owner calls enableTrading() once, after the oracle warmup. The app and landing read the active contract state, including a disabled or paused market.
The new launch hook charges a total buy fee of 25% for the first two blocks, then reduces it by one percentage point every two blocks until 1% at block 48 after enablement. Sells pay the normal 1% pool fee throughout. These totals include the 1% pool fee; gas and price impact are separate. The additional launch charge is sent as WETH to the configured fee recipient, not automatically to rewards.
The two-auction controller schedules after-hours at 10:00–12:00 and 22:00–00:00 Europe/Madrid, with the final five minutes of each window reserved for settlement. The actual configured controller is authoritative: test deployments may use a different schedule. The app reports a pending settlement rather than assuming that trading has reopened.
The deployment script targets chain ID 4663, validates the canonical Uniswap v4 dependencies and supports either a one-pass deployment or a two-stage CREATE2 flow.
Deploy and configure protocol contracts while the predicted TIDE address can still have no bytecode.
Create exactly the precomputed token, allocate supply to the manager and finalize reward/exclusion configuration.
Check owners, bytecode, PoolKey, official dependencies, exclusions and cross-contract references.
Pool launch is deliberately separate from deployment and should only happen after final verification.
forge fmt --check forge build --sizes forge test -vv forge lint ./scripts/check-storage-layout.sh