Turnkey Policies

Turnkey policies define who can sign and what can be signed. OpenPond uses them to keep automation useful without giving the operating wallet broad default power.

Wallet roles (quick model)

• Personal wallet

  • Human-controlled vault wallet.
  • Intended for long-term custody.
  • Acts as the recovery destination for operating-wallet funds.

• Operating wallet

  • Execution wallet used by automation and tools.
  • Holds active working balance.
  • Must stay narrowly scoped through policies.

OpenPond policy design separates these roles on purpose: personal wallet is the safety anchor, and operating wallet is tightly constrained unless explicit allow policies are added.

How policy enforcement works

• Every signing request is evaluated against Turnkey org policies.
• Policy actions are allow or deny rules with consensus requirements.
• Root quorum is authoritative in Turnkey. If the delegate/bot user is still in root quorum, that user can approve activities outside scoped policy intent.
• Effective behavior follows strict precedence:
  • explicit deny wins
  • then explicit allow
  • otherwise implicit deny

This means policy scope should remain narrow and additive. If something is not explicitly allowed, it should fail closed.

Root quorum invariant (critical)

• Root quorum must remain human-only for policy hardening to hold.
• Delegate user should be non-root and limited by policies.
• If delegate remains root, a scoped policy can appear to be "ignored" because root approval can still pass.

Quick symptom:

• A withdraw/sign request to a non-allowed destination succeeds even though your policy condition is destination-scoped.

Default baseline (new provisioning)

In the current policy-hardening rollout, OpenPond uses two base policies when your wallet is provisioned:

• Personal vault (human-only)

  • Only you can sign.
  • Used for long-term funds.

• Operating wallet (strict baseline)

  • Bot or human can sign.
  • Default baseline is limited to native ETH transfer from operating -> personal vault.
  • ERC20 transfers are not allowed by default.
  • Broad ERC20 contract-call scope is not enabled by default.
  • Generic approve and transfer token flows are denied until you add explicit scoped policies.

Default operating condition:

Security intent:

• You can always unwind native ETH to personal wallet.
• Token movement requires explicit, reviewable policy additions.

Bot path vs human path

• Policies are most important for automation paths that use the operating signer (delegate/bot user).
• Logged-in policy admin actions in the UI are human-authenticated operations, not bot self-grants.
• If you manually perform recovery in UI as the logged-in user, you can keep bot policy scope tighter and avoid unnecessary recovery grants.

Existing accounts and resync

• Existing accounts may still have legacy operating policies from older provisioning.
• If available in your environment, use Wallet Manager -> Policies -> Resync policies to apply the strict baseline on an existing account.
• Resync aligns the default policy and removes legacy broad variants while preserving your additive custom allow policies.

Hyperliquid path (Arbitrum first)

Hyperliquid setup is the initial explicit allow path. It is intentionally narrow and starts with Arbitrum token flow scope.

Hyperliquid actions require EIP-712 signing. OpenPond ships presets you can add in Wallet Manager -> Policies:

• Hyperliquid signing (testnet / mainnet)
• Hyperliquid builder fee (testnet / mainnet)
• Hyperliquid bridge transfer scope (Arbitrum) for setup flows that move USDC from operating wallet to approved bridge addresses.
• Hyperliquid recovery transfer scope (Arbitrum) for returning bridged token funds from operating wallet back to personal wallet (needed only when bot automation performs recovery).

Initial production token path:

• Arbitrum mainnet USDC for Hyperliquid deposit and recovery.

Testnet parity path:

• Arbitrum Sepolia HYPE_USDC in the same scoped model.

These presets allow required Hyperliquid actions while keeping unrelated token and contract paths blocked.

ERC20 policies

• Non-Hyperliquid ERC20 flows are opt-in.
• Add scoped policies by token + chain + allowed recipient/spender.
• Prefer narrow presets/templates over broad custom conditions.
• Relay swap/bridge flows should use scoped policy creation with explicit chain/token/recipient constraints. Where available in your environment, /swap can pre-create these Relay policies from current Relay chain metadata.
• For Relay-powered bots, grant only the exact approve/swap/bridge scopes needed for that strategy.
• Operating -> personal ERC20 recovery can remain a manual logged-in UI action if you want to keep bot permissions narrower.
• There is no default global "any ERC20 on any chain" allow path in this model.

Policy admin boundary (who can change policies)

Policy mutations are treated as admin operations:

• Policy create/delete/resync requires an authenticated logged-in app user session.
• App actions enforce user identity and org/team access checks before mutating policy state.
• OpenTools tools cannot create, update, or delete policies.
• Operating signer credentials cannot self-grant broader permissions.
• API execution paths can only use capabilities already permitted by existing policies.

Where to manage policies

Open Wallet Manager → Policies from any project overview:

• Project overview → Manage → Policies

Each policy has two parts:

• Consensus: who must approve (bot, human, or both).
• Condition: what is allowed to be signed.

Use the presets first; only create custom policies if you need additional scope.

Policy approvals

• Policy creation/deletion/resync is a human-admin action in the app session.
• Per-mutation OTP requirement is not mandatory by default in this rollout.

Practical security checklist

• Keep most funds in personal wallet.
• Keep operating wallet funded only for active tasks.
• Verify root quorum is human-only after provisioning or repair.
• Use strict default plus scoped additions.
• Add policies per chain + token + recipient/spender, then test.
• Use resync on existing accounts before relying on strict-default assumptions.