Money

Bridge

How value moves from an arbitrary source asset into the single collateral asset a position can rest against: and where it sits once it has.

Status

Bridge client liveTreasury wallet testPer-user wallets not builtPlayer withdrawals operator-owned

Test treasury, not customer custody

The configured destination is a test treasury wallet. This build is not approved to hold customer funds, and no part of this page is such an approval.

The path value takes

text

source asset (any supported chain)
        │
        ▼
   bridge transfer          ← quoted, minimum-bounded, status-tracked
        │
        ▼
   USDC on Polygon          ← the single collateral asset
        │
        ▼
   controlled wallet        ← treasury today; per-user is a deployment choice
        │
        ▼
   ledger credit            ← the separate decision that it is a player’s money

Four steps, and the last one is not like the others. The first three are transport: they are observable on a chain and they either complete or fail. The fourth is an accounting decision, made once, in a database transaction that also writes the entry. Collapsing those two is how a bridge retry becomes a double credit.

Why one collateral asset

Contracts settle in a single stablecoin. A player may hold anything; a position may only be collateralised in one thing. The bridge exists to close that gap, and it is the only reason it exists: it is not a general-purpose swap and should not be offered as one.

Routes are whatever the bridge currently publishes. We do not keep a local list, so an asset we would like to support but the route does not simply will not appear.
Each route carries its own minimum. Below it, a transfer does not bridge and the funds are stranded rather than returned.
Non-EVM chains are keyed by chain id, never by display name, because a name can change and an id cannot.

Custody models

Model	What it means	State
`operator_treasury`	One controlled wallet holds collateral for all of an operator’s players; entitlement is tracked in the ledger.	Implemented, pointed at a test wallet.
`per_user_wallet`	A distinct wallet per player, so on-chain position and internal entitlement line up one to one.	Modelled as a configuration option. Not built.

The choice is a deployment and licensing question rather than an API one. It changes who holds what, which regulator cares, and what a bankruptcy looks like: none of which a request body should be able to select.

Paying a player out is yours, not ours

You hold your customers' cash. Deposits, withdrawals, address verification and travel-rule handling sit on your side of the boundary, against your own ledger, under your own licence — Predicta never takes custody of a player's funds and has no route that pays one out.

What Predicta returns is the exact amount to book: authorizationAmount and actualDebit when a position opens, releaseAmount when it does not, sellProceeds on an exit, and settlementCredit or voidCredit when a market resolves. You move the money; we tell you the figure, and it is exact.

The bridge on this page is a different thing entirely: it moves your collateral into the asset a position rests against. It is not a player cash-out path and must not be built into one.

What a partner should assume

Bridging is slow and occasionally fails

Treat funding as an asynchronous flow with a visible pending state, not as a form submission. A player who has sent funds and sees nothing will contact support long before the bridge does anything wrong.

The address is per deposit, and permanent to it

Do not cache an address across deposits or reuse one issued for a different route. Everything about a deposit, its route, its minimum, its uniqueness guard, is keyed to the row that produced the address.

Only `credited` is spendable

Do not let a player stake against detected or bridging funds. The chain having seen a transaction is not the same claim as the money being theirs, and the gap between those two is where a double-spend would live.