Skip to main content
Describe the cohort you want and get back a draft query against the curated schema. Useful when you know the audience but don’t want to start from an empty editor.

​
Modes and credit cost

Repeating the same prompt within 6 hours returns the cached result and costs nothing. Running the resulting SQL is always free; only generation consumes credits. Other AI features draw from the same monthly AI-credit allowance at higher rates. A copywriting or segment-rule suggestion costs 5, and a turn with the AI assistant, which can reason and run queries, costs 10. Your plan’s allowance is listed on Plans and billing. If your workspace runs out of credits, generation is blocked while the editor itself keeps working. You can still write and run SQL by hand.

​
Writing a good prompt

The strongest prompts name four things:
  • The behavior to isolate: minted, swapped, clicked, or went quiet
  • The time window, such as “in the last 30 days”
  • The chain or contract, when relevant
  • The business goal: win-back, VIP targeting, or a governance reminder
The second prompt names the chain, the threshold, both time windows, and the goal, so the generated query needs far less editing.

​
More examples

  • Recent minters on Base who haven’t clicked a campaign in the last 30 days.
  • High-value wallets with declining activity that should enter a churn win-back flow.
  • Contacts who clicked a governance reminder but have no VoteCast activity.
  • Holders of more than three NFTs from one collection who have never received an email.

​
Reviewing the result

Generated SQL is always re-validated against the schema before it reaches you, so it can’t contain unsupported tables or write operations. What validation cannot check is whether the query answers your actual question.
The most common failure isn’t invalid SQL. It’s a valid query for a subtly different question. Read the WHERE clause against your original intent, line by line.
wallet_activity_summary is per wallet per chain; nft_holdings is per token. Joining either to a per-wallet table fans out rows. If a wallet appears twice, that’s why; add a chain filter or aggregate.
Wallet casing isn’t normalized. Joins should use lower() on both sides or they’ll silently drop rows.
An unbounded query over all history usually isn’t what you meant, and is far more likely to hit the 5-second timeout.
Saving as a segment requires a wallet column named wallet_address, wallet, or address. Reports are free-form.

​
After generating

Run it on a narrow window first, spot-check a few rows against wallets you recognize, then save. Once saved, the query re-runs for free, so the credit cost is one-time, not per use. Treat generated SQL as a first draft from someone who knows the schema but not your business.