> ## Documentation index
> Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt
> Use it to discover every available page before exploring further.

# Pascal

> The build request schema, signing scheme, and bounds for 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.

:::caution[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.
:::

:::note[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.
:::