Private preview

Privy data Private preview

Use Stripe Sigma or Stripe Data Pipeline to analyze Privy users, wallets, and asset balances.

Analyze your Privy app users, wallets, and asset balances with Stripe Sigma or Stripe Data Pipeline. Use these datasets for SQL-based reports or warehouse analysis of user adoption, wallet inventory, or historical asset holdings.

The datasets contain data for Privy accounts and apps associated with your Stripe account and refresh on a daily batch schedule. Privy data is typically around 24 hours delayed. Delays can be longer depending on the data source and delivery destination. The datasets don’t provide real-time wallet information.

Get access

Privy data is available in private preview. Access requires an eligible Stripe plan and approval for the Stripe account associated with your Privy account.

1. Contact your Privy or Stripe account team to request access and confirm which Stripe account will receive your data.
2. After your account team enables access, query the tables in Sigma or configure a Data Pipeline destination to use them in your warehouse.
3. Find your tables in Available data . See the data schema guide for how to browse tables and columns.

The SQL examples on this page use Sigma syntax. Adapt them to your warehouse’s SQL dialect when you use Data Pipeline.

Test mode contains production Privy data

Stripe live mode and test mode contain the same production Privy data. Test mode doesn’t provide a separate dataset for Privy development apps.

Available data

The three tables cover different reporting needs. Users and wallets are current snapshots; wallet assets contain historical daily balances.

All three tables include privy_account_id, account_name, app_id, and app_name to identify the Privy account and app. Account and app names reflect their current values.

Users

Each row in privy_external_users represents one current non-deleted user in an app, identified by app_id and user_id. The table includes:

• Lifecycle and activity fields such as created _ at , updated _ at , last _ active _ at , last _ accepted _ terms _ at , and is _ imported .
• Indicators for linked authentication methods, such as has _ email , has _ phone , has _ passkey , has _ custom _ jwt _ signer , is _ guest , and social login indicators.
• Linked wallet indicators: has _ embedded _ wallet , has _ external _ wallet , and has _ smart _ wallet . has _ wallet also refers specifically to an embedded wallet; has _ any _ wallet _ linked _ account covers all three wallet types.

The indicators describe active linked accounts, not whether a user has recently signed in. The table excludes deleted users and direct contact values such as email addresses and phone numbers.

The following example summarizes current users and selected linked account capabilities by app. It also counts users with recorded activity in the last 30 calendar days, including today:

SELECT
 app_id,
 app_name,
 count(*) AS current_users,
 count_if(date(last_active_at) BETWEEN date_add('day', -29, current_date) AND current_date) AS users_active_last_30_days,
 count_if(has_email) AS users_with_email,
 count_if(has_passkey) AS users_with_passkey,
 count_if(has_embedded_wallet) AS users_with_embedded_wallet,
 count_if(has_external_wallet) AS users_with_external_wallet
FROM privy_external_users
GROUP BY 1, 2
ORDER BY current_users DESC

current_users counts the current non-deleted snapshot, not recently active users. Use last_active_at to define an activity window, taking the dataset’s delivery delay into account.

Wallets

Each row in privy_external_wallets represents one current wallet profile for an app, identified by app_id, wallet_address, and chain_type. The table includes:

• The public wallet address and chain family, such as evm or solana .
• Wallet classifications in wallet _ type , wallet _ shape , and custody _ category , plus is _ bridge _ owned and is _ tee indicators.
• Connection, import, and export fields: first _ connected _ at , first _ imported _ at , first _ exported _ at , is _ imported , and is _ exported .

The following example summarizes wallet profiles by app, chain family, wallet type, and custody category:

SELECT
 app_id,
 app_name,
 chain_type,
 wallet_type,
 custody_category,
 count(*) AS wallets,
 count_if(is_imported) AS imported_wallets,
 count_if(is_exported) AS exported_wallets
FROM privy_external_wallets
GROUP BY 1, 2, 3, 4, 5
ORDER BY wallets DESC

This table doesn’t include a user-to-wallet mapping. Joining users and wallets on app_id alone matches every user to every wallet in the app, rather than identifying which wallets belong to a user.

Wallet assets

Each row in privy_external_wallet_assets represents one daily closing balance, identified by app_id, wallet_address, balance_date, chain, and token_address. The table includes:

• The balance’s UTC date in balance _ date , the blockchain network in chain and chain _ id , and token identifiers in token _ address and token _ name .
• Token quantities and USD values in token _ balance and usd _ balance , plus is _ stablecoin classification.
• Current wallet attributes: current _ wallet _ type , current _ wallet _ shape , current _ custody _ category , is _ currently _ bridge _ owned , and is _ currently _ tee .
• Position and valuation metadata: position _ type , valuation _ source , wrapper _ nav _ per _ share _ usd , curator _ vault _ address , and underlying _ token _ address .

The following example summarizes daily USD balances for the last 30 completed calendar days. It groups balances by app, chain, token, and position type:

SELECT
 date(balance_date) AS balance_date,
 app_id,
 app_name,
 chain,
 token_address,
 token_name,
 position_type,
 count(DISTINCT wallet_address) AS wallets,
 sum(usd_balance) AS total_usd_balance
FROM privy_external_wallet_assets
WHERE balance_date >= date_add('day', -30, current_date)
 AND balance_date < current_date
GROUP BY 1, 2, 3, 4, 5, 6, 7
ORDER BY balance_date DESC, total_usd_balance DESC

When interpreting asset balances:

• The table includes only positive balances that pass Privy’s asset filters. Privy filters reported assets using token verification, market liquidity, trading volume, and valuation checks to reduce spam and anomalous balances. A missing row doesn’t necessarily mean a zero balance.
• Use balance _ date to identify the date represented by each balance. The most recent dates might not yet be available.
• Historical balances use current wallet and app attribution. They don’t preserve historical ownership changes.
• Rows with position _ type = 'yield _ wrapper _ share' represent wrapper shares held by a wallet. The underlying _ token _ address and curator _ vault _ address fields describe the position. They aren’t additional balances, so don’t add them to the position’s value.
• Coverage is limited to supported assets held by Privy-tracked wallets. A Bridge-owned wallet can appear when its address is in the Privy wallet registry, but this table isn’t a complete Bridge ledger.