Operations
Running a market-making desk on Oracle means moving real capital across the Solana → Fogo bridge and holding inventory on Fogo. This page covers the operational limits and infra expectations.
Deposit tiers
Oracle enforces per-transaction deposit caps that scale with operator trust. Market makers should request LP tier before funding.
| Limit | Retail | LP | Institutional |
|---|---|---|---|
| Min USDC per deposit | 1 USDC | 1 USDC | 1 USDC |
| Min SOL per deposit | 0.05 SOL | 0.05 SOL | 0.05 SOL |
| Max USDC per tx | 10,000 | 1,000,000 | 10,000,000 |
Tier assignment lives on-chain in a UserTier PDA on oracle-vault. Absent record = retail default. Admin upgrade is a single tx:
POST /admin/bridge/user-tier
X-Admin-Key: <admin key>
{
"user": "<bs58 fogo pubkey>",
"tier": 1 // 0 = Retail, 1 = LP, 2 = Institutional
}
Your GET /v1/deposit/bridge-address response reflects your current tier in max_usdc_per_tx_micro, so the frontend shows the right cap automatically.
Daily bridge cap
Regardless of tier, the protocol enforces a global daily aggregate cap of 100,000 USDC across all bridge deposits. Once the cap is hit, new deposits above the minimum queue until 00:00 UTC. Your deposit-address response includes a live counter:
{
"max_usdc_per_tx_micro": 1000000000,
"daily_cap_remaining_usdc_micro": 85000000000
}
If you're planning a large fund-up, check daily_cap_remaining_usdc_micro first. Institutional deposits that need to exceed the daily cap should be scheduled with the Parti team — we can run a multi-day sequence or raise the cap for a named counterparty.
Bridge minimums
Below the minimums, bridge fees exceed the deposited value:
- USDC: 1 USDC (1,000,000 micro-USDC)
- SOL: 0.05 SOL (50,000,000 lamports) — auto-swapped to USDC via Jupiter before bridging
Sub-minimum transfers are rejected; funds sit in the deposit address (recoverable — see the deposit FAQ).
Infra expectations
Uptime directly maps to earnings. The liquidity rewards score is summed over 2880 samples/day. Missing a 5-min window costs ~0.2% of your daily max.
Minimum viable stack:
- Order placement: HTTP or WebSocket. The signer accepts both. Sub-second round-trip from your quote engine to resting order is standard.
- Market-data feed: WebSocket (
wss://ws.parti-oracle.pbcapps.dev/v1/ws). REST polling is technically allowed but will lose you money on fast-moving markets. - Failover: two independent quote instances across regions, one active, one hot-standby. Oracle's signer supports concurrent connections from the same key.
- Monitoring: watch
/v1/balance/${PUBKEY}for unexpected drawdown and/v1/rewards/leaderboardfor rank regression.
The reference bot in oracle-lp implements none of this HA — it's designed as a starting point, not production infra.
Risk controls
Currently enforced by the protocol:
- Per-tx deposit cap (tier-based, see above)
- Daily bridge cap (100k USDC aggregate)
- Circuit breaker: bridge executor can be disabled by admin if an anomaly is detected; already-bridged funds unaffected
- Market halt: individual markets can be halted to cancel outstanding orders and freeze new submissions
Currently not enforced — you must implement on your side:
- Per-market position limits
- Max drawdown stop-outs
- Cross-market correlation hedging
- Adverse-selection detection (toxic flow throttling)
Support
Market maker ops questions, tier upgrade requests, scheduled large fund-ups: contact the Parti team through the channel you were onboarded on.