Skip to main content
Use the prompts below to have an AI coding agent (Claude, Cursor, Copilot, etc.) integrate Ground’s Portfolio Wallets API into your product. Each prompt is tailored to a specific customer type so the agent optimizes for your product’s goals. How it works: Each prompt runs a multi-step process. The agent will first analyze your codebase and ask clarifying questions before writing any code. This avoids hallucinations from incorrect assumptions about your stack, infrastructure, or architecture.
These prompts are designed for use against the sandbox environment (https://sandbox.groundtech.co). Do not point at production until you have validated the integration end-to-end in sandbox.

​
Prerequisites

Before running any prompt, make sure you have:
  1. A Ground sandbox API token (contact your Ground rep if you don’t have one)
  2. Your AI coding agent has access to your project’s codebase
  3. Access to Ground’s API documentation

​
Neobank / Savings Product

Use this if you are building a consumer or business banking product where end-users hold balances and expect to earn yield on idle funds. 
You are integrating Ground's Portfolio Wallets API into our product. Ground is
a yield infrastructure provider -- their Portfolio Wallets API lets us allocate
customer stablecoin deposits across multiple yield sources (e.g. overcollateralized
lending, delta-neutral strategies, stablecoin yield tokens) via a single REST API.
Ground handles allocation, rebalancing, withdrawals, and reporting.

We are a neobank / savings product. Our goal is to offer yield on customer deposits
with these priorities:
  - Capital preservation and liquidity (customers expect to withdraw at any time)
  - Transparent yield display (earned amounts, current APY)
  - Webhook-driven architecture so our UI updates in real time

Before writing any code, do the following:

1. Read our existing codebase to understand:
   - What language/framework we use for our backend
   - How we currently handle user accounts and balances
   - How we process deposits and withdrawals today
   - Whether we have an existing webhook ingestion system
   - How we store secrets and API credentials
   - What database we use and how we manage migrations

2. Read Ground's API documentation at https://docs.groundtech.co to understand:
   - API conventions (auth, pagination, idempotency, error handling)
   - The wallet lifecycle (create, deposit, earn, withdraw)
   - Webhook events and signature verification
   - Yield sources and strategy quoting
   - The withdrawal approval flow (Turnkey signing)

3. Then present a written integration plan that covers:
   - Which parts of our codebase you'll modify or create
   - How you'll map Ground wallets to our user model (1:1 per user? pooled?)
   - Which yield strategy you recommend and why, given our liquidity needs
   - How you'll handle webhook ingestion and signature verification
   - How you'll surface balances and yield to our users
   - How you'll handle the withdrawal -> Turnkey approval -> completion flow
   - What new database tables/columns are needed
   - What new environment variables are needed

Do NOT write any code yet. Wait for my approval of the plan before proceeding.

​
Cross-Border Payments / Stablecoin Money Movement

Use this if you are building a cross-border payments, remittance, or stablecoin money movement product (similar to Bridge, OpenFX, etc.) where funds transit through your platform and you want to earn yield on float/held balances. 
You are integrating Ground's Portfolio Wallets API into our product. Ground is
a yield infrastructure provider -- their Portfolio Wallets API lets us allocate
stablecoin balances across multiple yield sources via a single REST API. Ground
handles allocation, rebalancing, withdrawals, and reporting.

We are a cross-border payments / stablecoin money movement platform. Our goal is
to earn yield on float -- the stablecoins that sit in our system between when we
receive funds and when we pay them out. Our priorities are:
  - Instant or near-instant liquidity (we need to pay out on short notice)
  - Multi-chain support (we operate across multiple EVM chains)
  - Automated treasury management (minimal manual intervention)
  - Yield is a secondary revenue stream, not our core product

Before writing any code, do the following:

1. Read our existing codebase to understand:
   - What language/framework we use
   - How we currently hold and move stablecoins
   - Our payment/transfer lifecycle (receive -> hold -> payout)
   - What chains we currently operate on
   - How we manage treasury wallets today
   - How long funds typically sit idle (minutes? hours? days?)
   - Whether we have an existing webhook ingestion system
   - How we store secrets and handle environment configuration

2. Read Ground's API documentation at https://docs.groundtech.co to understand:
   - API conventions (auth, pagination, idempotency, error handling)
   - The wallet lifecycle (create, deposit, earn, withdraw)
   - Webhook events and signature verification
   - Yield sources -- especially which have instant liquidity (maxProcessingTime: PT0H)
   - Withdrawal preview and the withdrawal lifecycle
   - Cross-chain bridging behavior (CCTP) and bridge domain boundaries
   - The Turnkey transaction approval flow

3. Then present a written integration plan that covers:
   - How you'll architect the Ground wallet(s) relative to our payment flows
     (e.g. one treasury wallet vs. per-corridor wallets)
   - Which yield strategy you recommend -- given our need for instant liquidity,
     you should heavily weight or exclusively use instant-liquidity sources
   - How you'll sweep idle funds into the Ground wallet
   - How you'll trigger withdrawals when we need to pay out
   - The timing budget: how withdrawal timing (unwind + bridge) fits within
     our payout SLA
   - How you'll handle the Turnkey approval step in the withdrawal flow
   - How you'll use webhooks vs. polling for withdrawal status tracking
   - What changes to our database schema are needed
   - What new environment variables are needed

Do NOT write any code yet. Wait for my approval of the plan before proceeding.

​
Non-Custodial Wallet Provider

Use this if you are building a self-custody wallet, smart wallet, or MPC wallet product where users hold their own keys and you want to offer yield features without taking custody of funds. 
You are integrating Ground's Portfolio Wallets API into our product. Ground is
a yield infrastructure provider -- their Portfolio Wallets API lets us allocate
stablecoin deposits across multiple yield sources via a single REST API. Ground
handles allocation, rebalancing, withdrawals, and reporting. Ground wallets use
Turnkey for non-custodial key management -- private keys are never held by Ground.

We are a non-custodial wallet provider. Our goal is to offer yield-earning
features to our users while preserving our non-custodial architecture. Our
priorities are:
  - Users remain in control of their funds (non-custodial UX)
  - The Turnkey approval flow is critical -- users must approve withdrawals
  - Clear separation between user funds (each user gets their own Ground wallet)
  - Transparency: users should see exactly where their funds are allocated and
    what yield they are earning

Before writing any code, do the following:

1. Read our existing codebase to understand:
   - What language/framework we use for our backend and client apps
   - How users currently manage their wallet(s) in our product
   - Whether we already integrate with Turnkey or a similar key management system
   - How we handle transaction signing and approval UX today
   - How we display balances and transaction history to users
   - Whether we have an existing webhook ingestion system
   - How we store secrets and handle environment configuration

2. Read Ground's API documentation at https://docs.groundtech.co to understand:
   - API conventions (auth, pagination, idempotency, error handling)
   - The wallet lifecycle (create, deposit, earn, withdraw)
   - Webhook events and signature verification
   - The transaction approval flow -- specifically how Turnkey activity IDs
     surface on withdrawal payout legs (pending_customer_approval status)
   - Yield sources and strategy quoting
   - How deposit addresses work (per-chain addresses per wallet)

3. Then present a written integration plan that covers:
   - How you'll create and manage Ground wallets per user (1:1 mapping)
   - How the yield opt-in flow works from the user's perspective
   - Which yield strategies to offer and whether to let users choose
   - How users will fund their Ground wallet from their existing wallet
   - How you'll surface positions, balances, and earned yield in the UI
   - How you'll integrate the Turnkey approval into our existing signing UX --
     this is the most important part for our architecture
   - How you'll handle the full withdrawal lifecycle from user request through
     Turnkey approval to fund delivery
   - What new backend endpoints, database tables, and client UI are needed
   - What new environment variables are needed

Do NOT write any code yet. Wait for my approval of the plan before proceeding.

​
Tips for best results

  • Run Step 1 first, review the plan, then run Step 2. The two-step approach prevents the agent from making wrong assumptions about your codebase.
  • Answer the agent’s questions. During Step 1, the agent will likely ask clarifying questions about your architecture. Answer them — this is by design and prevents hallucinated code.
  • Use sandbox first. All prompts target https://sandbox.groundtech.co. You can simulate deposits without real funds using the POST /v2/wallets/:id/deposits/simulate endpoint.
  • Check the webhook handler carefully. Signature verification is security-critical. Review the generated Ground-Signature verification code against our reference implementation.
  • The Turnkey approval flow is product-specific. The prompts intentionally leave room for the agent to ask how your signing infrastructure works rather than assuming a specific Turnkey integration pattern.