Pascal

Step zero — from nothing to your first trade

1. Create the account. Start at the venue’s site, create an eligible Pascal account, and connect its Solana-format custody wallet. The allowed sources do not document Pascal’s signup or identity checks, so confirm those details with the venue.
2. Set up signing. A fresh user must first create a Solana wallet and secure the seed phrase offline. Sign with that wallet or register a revocable Pascal trading key. There is no relay API credential, and Predictefy never sees either private key.
3. Fund it. Keep SOL in the custody wallet for Solana network fees, plus the balance Pascal requires for the first order. The funding registry verifies no collateral asset, deposit route, or numeric minimum and exposes no hosted helper. GET /v1/bridge/quote may price a cross-chain route; it is not a verified Pascal deposit path.
4. Allow time. Budget about 1–2 hours for a first wallet and venue setup; any account approval can take longer. Pascal itself restricts US users, so do not fund or trade from the US.

What you need first

• Production status: Armed for build, submit, and cancel — armed 2026-08-12; fleet-verified 2026-08-15. Status refresh is served as well; GET /v1/exec/venues reports only the three write verbs, so it will not show up there.
• Wallet and chain: A Solana-format Ed25519 custody wallet. The wallet key may sign directly, or a registered, revocable delegated Pascal trading key may sign the permit.
• Venue account: Yes. Use an eligible Pascal account and its existing custody wallet.
• Credentials: No relay API credential. The private wallet or trading key stays client-side; only the base58 permit signature and public owner cross the API.
• Funding: Use the existing Pascal custody wallet. The funding registry does not verify a collateral asset or deposit route and there is no hosted funding helper.

Pascal is a strict server-built binary-permit lane, and it is armed in production: PASCAL_TRADE_ENABLED=true was set on 2026-08-12 and the row was fleet-verified on 2026-08-15, so GET /v1/exec/venues lists Pascal with build, submit, and cancel. That single flag remains the registration gate, and flipping it back off is an owner/compliance operation — so keep reading the live /v1/exec/venues row rather than trusting this page for runtime state. What arming did not change: there is still no hosted funding helper and no verified collateral deposit route.

Field	Type	Required	Meaning
market	Predictefy catalog market id	yes	Resolves Pascal’s symbol from the catalog; tick parameters and taker fee come from a live venue read
side	YES or NO	yes	Outcome being bought or sold
isBuy	boolean	yes	Maps the outcome intent to Pascal’s native bid or ask
price	probability in (0, 1), at most six places	yes	Must align with the market’s tick at that price; see the tick rule below
size	positive u64 integer	yes	Contract quantity
owner	base58 Ed25519 wallet public key	yes	Custody wallet
signer	base58 Ed25519 public key	yes	Trading key that signs the permit; never defaulted from owner
tif	GTC, GTT, or IOC	no	Defaults to GTC, or GTT when expiresAt is present
postOnly	boolean	no	Incompatible with IOC
expiresAt	future Unix milliseconds	GTT only	Required for GTT; forbidden for other time-in-force values

signer is never defaulted. Pascal signs place and cancel permits with a registered trading key, so an omitted signer is refused with a 400 instead of silently signing as the custody wallet. An account whose wallet is its own signing key simply names that wallet as signer.

The server resolves the Pascal symbol from the catalog, converts price to exact millionths, derives client_order_id from the build idempotency key, and fixes the millisecond timestamp and 5,000 ms receive window. The returned artifact pins permit version 1, production deployment 3, the 232-byte layout, and the published off-chain-fields digest. Its message is hex encoding of the permit bytes; decode the hex and sign those bytes, not the text characters, with Ed25519. Submit only { executionId, signature, owner }, with the signature in base58. Predictefy re-encodes and byte-compares the stored artifact, checks freshness, and verifies the signature against the stored signer before relaying the stored request. It persists only the permit, signature, and owner; the private trading key never transits the service.

Cancellation is also client-signed. Call the standard cancel route with { signer }, sign the new 96-byte cancel permit, then submit the cancel execution’s ID with { signature, owner }. The cancel inherits the original owner and client order id, while allowing the owner to select a currently active trading key. Pascal supports at most ten delegated trading keys; they are revocable, expire within 365 days, and cannot withdraw. That split from the custody wallet is a meaningful custody positive.

Confirming an order afterwards needs no credential. Pascal signs writes only — its read API is unauthenticated — so POST /v1/exec/pascal/orders/{executionId}/refresh takes an empty body, and the server reads Pascal’s own account snapshot and fill history for the wallet named on the stored permit. The background reconciler uses that same keyless read, so a Pascal order can also be resolved server-side without you asking.

That read is deliberately one-sided, and this is a property of the venue rather than a gap in the lane. Pascal’s order objects carry no status field: a closed order simply leaves the open-order list, whether it filled, was canceled, expired, or was resolved by the matching engine. Disappearance is therefore not a verdict and is never turned into one. Refresh reports filled only when the account’s own fill rows for that exchange order id cover the size you built, and acked while the order is still listed on the book; every other shape leaves your stored status untouched. An order canceled or expired at Pascal keeps its last known Predictefy status, because the venue publishes no reason and inventing one would be worse than saying nothing.

“Every other shape” includes a venue response that does not parse the way the contract says it should. Order ids and sizes are matched as exact u64 decimal strings — never coerced through a number, which would round a 19-digit id onto its neighbour and credit you another order’s fills — and repeated trade_id values are collapsed to one fill before anything is counted or stored. A row that fails any of those checks, or that reports a market you did not ask about, or two rows that disagree under one trade_id, discard the whole read rather than half of it. You get your stored status back, which is the same answer as a venue timeout.

Collateral is catalog-bound: a native bid locks quantity × price, while a native ask locks quantity × (1 − price). The fee estimate uses that market’s live taker_fee_rate.

Pascal’s tick is price-dependent, so tick_size_min alone does not describe it. With p' = min(price, 1 − price), the tick is max(10^(floor(log10(p')) + 1 − tick_sig_figs), tick_size_min), evaluated on the native price actually being signed. A market with tick_size_min = 0.001 and tick_sig_figs = 2 therefore accepts 0.55 and 0.055 but refuses 0.555; the min(p, 1 − p) mirror keeps 0.995 as fine-grained as 0.005. Off-tick prices are refused at build with a 400 naming the tick, rather than by Pascal’s INVALID_PRICE after you have already signed the permit.

Pascal eligibility — current, not superseded

Arming changed nothing here. Pascal’s Terms PDF restricts Australia, Belgium, France, Germany, Italy, the Netherlands, Ontario, Poland, Quebec, Russia, Singapore, Taiwan, Thailand, the UK, the US, and comprehensively sanctioned jurisdictions including Iran, Syria, Cuba, North Korea, Crimea, Donetsk, and Luhansk. Its automated-access and data/API clauses remain under owner review. Eligibility and enforcement are the operator/compliance responsibility; an armed lane is not permission to trade from a restricted location.

Historical arming context — superseded 2026-08-15

Superseded 2026-08-15 (the arming status only — the restrictions above are current). Before arming, this page recorded measured venue-wide flow of only about $3.2k notional/day on 2026-08-11 despite real displayed depth, and stated that source-ready code was not permission to arm the lane. Enablement was taken as an explicit owner decision on 2026-08-12.