Turnkey Custody And Asset Safety
PredictDog currently uses Turnkey as the custody and signing layer for user-linked wallets.
The current landing page highlights the platform's Turnkey-backed wallet architecture and the venue ecosystem it connects to, which matches the user-facing explanation on this page: custody and signing are separated from venue-specific execution surfaces.
This page explains what that means in practical user terms, how it relates to Polymarket and Predict.fun, and why the current architecture is designed to keep user assets separated and harder to misuse.
Short answer
The current model is designed around these principles:
- your wallet authority is not treated like a shared platform hot wallet
- PredictDog uses Turnkey-hosted wallet identity and signing instead of storing a normal raw owner private key in the application database for the main Polygon path
- user funds are handled through user-linked wallet structures, not by mixing everyone into one omnibus venue wallet for trading
- high-risk asset-moving actions such as withdraw are intentionally separated from ordinary automated trading
- venue credentials are not treated as equivalent to wallet authority
Current runtime model
The current backend runtime wallet mode is turnkey_proxy.
That means PredictDog currently combines two layers:
- a Turnkey-custodied owner wallet tied to the user
- a user-linked execution structure used where the venue requires it
For users, the important point is simple:
- Turnkey is the custody and signing authority
- PredictDog uses venue-specific execution structures on top of that authority when needed
One user, one isolated Turnkey organization
The current implementation is built around one Turnkey sub-organization per end user.
Why that matters:
- your wallet context is isolated from other users at the Turnkey organization level
- backend automation is scoped inside that user context rather than running against one shared wallet identity for everyone
- this reduces the chance that one user's wallet authority is confused with another user's wallet authority
This is one of the main reasons the current model is safer than treating all users as balances inside one shared platform trading wallet.
Why this is different from pooled custody
From a user perspective, the key safety question is usually:
Are my assets sitting in one big platform wallet with everyone else's funds?
The current architecture is designed to avoid that model for the main wallet authority path.
Each user is linked to their own Turnkey-backed wallet context. PredictDog does not treat Telegram login, API keys, or generic app sessions as a replacement for wallet authority.
How Polymarket works in the current model
Polymarket currently uses a proxy-style execution structure.
In practical terms:
- your Turnkey-custodied owner EOA is the authorization anchor
- the tradable Polygon address is the deterministic proxy Safe linked to that owner wallet
- PredictDog keeps the Polymarket trading path on that proxy wallet model rather than pretending the owner wallet and the exchange-facing wallet are the same thing
Why this helps users reason about safety:
- the exchange-facing execution address is user-linked, not a shared platform omnibus account
- the owner authorization layer remains tied to the Turnkey-custodied wallet
- withdraw and other asset-moving on-chain actions are not meant to be treated as the same permission as ordinary automated trade flow
How Predict.fun works in the current model
Predict.fun is intentionally not forced into the Polymarket proxy model.
The current design uses the Turnkey-hosted EOA path for Predict.fun.
In practical terms:
- Predict.fun reuses the existing Turnkey EOA signer capability
- it does not reuse Polymarket proxy wallet execution assumptions
- it does not reuse Polymarket CLOB credentials as if they were universal wallet authority
Why that matters:
- Predict.fun uses its own venue model and BNB-side trading context
- PredictDog keeps that venue boundary explicit instead of blurring multiple venues into one hidden wallet abstraction
- this makes it easier to reason about where approvals, balances, and signatures are actually happening
What PredictDog can automate, and what it does not treat as ordinary automation
The current architecture is not “backend can do anything with user funds at any time.”
The intended boundary is:
- routine trading-related signing can be performed through backend automation inside the user's Turnkey organization
- high-risk wallet operations remain separate
Current docs and implementation boundaries treat these as higher-risk operations:
- withdraw
- wallet export
- recovery-related actions
- fresh authorization flows
Those flows are intentionally kept bound to web and Turnkey-backed verification or user authorization, rather than being silently downgraded to ordinary app auth.
Why API keys and app sessions do not replace wallet authority
PredictDog has multiple auth layers, but they are not all equal.
Current rule:
- app login proves who you are inside PredictDog
- API keys can authenticate application access for normal routes
- venue tokens help talk to specific venues
- Turnkey-backed wallet authority remains the security boundary for actual wallet-sensitive actions
That means:
- an API key is not supposed to become a substitute for fresh wallet authorization on export or withdraw flows
- a browser session is not the same thing as full wallet authority for every sensitive operation
This separation is deliberate and important for asset safety.
Why venue credentials are not the same as wallet custody
PredictDog may store or cache venue-specific credentials or tokens to reduce repeated setup work.
Examples include:
- Polymarket venue auth material
- Predict.fun JWT state
But these are not the same thing as the underlying wallet authority.
Current implementation keeps wallet auth material in dedicated encrypted storage rather than treating ordinary session state as wallet custody.
The user takeaway is:
- venue access convenience should not be confused with ownership of the wallet authority itself
Why Telegram is not the wallet security surface
Telegram is currently the fast companion surface, not the primary wallet authorization surface.
That is why wallet creation, linking, withdraw-related authorization, and other higher-risk flows are web-first.
This is a safety feature, not just a product preference.
What “asset safety” means here in realistic terms
No custody design should be described as magic or risk-free.
What PredictDog can honestly say about the current model is:
- wallet authority is tied to Turnkey custody rather than a plain application-stored owner key for the main Polygon path
- users are isolated by Turnkey sub-organization instead of being merged into one shared wallet authority
- Polymarket and Predict.fun use different venue models, and PredictDog keeps that boundary explicit
- backend automation is intended to be policy-constrained rather than equivalent to full unrestricted user power
- high-risk asset-moving operations remain separated from ordinary trading automation
That combination is the main reason the current system is designed to keep user assets safer than a simpler shared-wallet model.
What users should still do
Even with the current custody model, users should still follow basic operational safety:
- use web for wallet-sensitive flows
- treat withdraw, export, and recovery prompts carefully
- do not assume one venue's readiness or approval state automatically applies to another venue
- read the exact product prompt when PredictDog says a rail, approval, or funding requirement is missing