Skip to main content
Give Onchain Suite a wallet address and it fetches that wallet’s on-chain history, normalizes it, and derives the metrics you actually segment and message on: portfolio value, recent activity, NFT holdings, an engagement score, and an estimated lifetime value. Enrichment is what makes a wallet-first audience useful. A raw address tells you nothing; an enriched profile tells you whether this is a dormant whale, an active minter, or a wallet worth a win-back.

What you get

Enrichment writes three datasets, all queryable in the SQL editor and joined together in contact_360.
One row per wallet in user_onchain_metrics:

Derived scores

Two fields are computed rather than fetched. Both are heuristics — useful for ranking and segmentation, not accounting.

Engagement score (0–100)

A weighted blend of recent activity, capped so no single signal dominates: A wallet with 20+ transactions, activity most days, a few collections, and a five-figure portfolio approaches 100. A dormant wallet trends toward zero.

Estimated LTV

A weighted blend biased toward realized value:
churn_risk is not an enrichment field — it’s derived at query time in contact_360 from last_activity_at: low within 30 days, medium at 30–60, high beyond 60. Enrichment supplies the activity timestamps that drive it.

Supported chains

Enrichment pulls from GoldRush (Covalent). EVM mainnets: eth-mainnet, base-mainnet, matic-mainnet, bsc-mainnet, arbitrum-mainnet, optimism-mainnet, sei-mainnet. Solana: solana-mainnet. Testnets including eth-sepolia, base-sepolia-testnet, and solana-devnet are also supported. A wallet is enriched per chain, so metrics reflect the chain you enriched it on. Enrich the same wallet on multiple chains to build a cross-chain picture — activity summaries are stored per chain.

When enrichment runs

1

On profile view (automatic)

Opening a contact profile that has a wallet triggers enrichment if it’s never been enriched or is more than 7 days stale. This keeps active profiles fresh without any work from you.
2

On project-settings save (automatic)

Saving project settings that include contract addresses enriches the holders of those contracts in the background.
3

On demand

Refresh a specific wallet, your contacts, or a contract’s holders whenever you need current numbers.
There is no fixed re-enrichment schedule — freshness is driven by the 7-day staleness check on view. You can force a refresh at any time, which bypasses the response cache.

Enriching on demand

Three ways to enrich beyond the automatic paths: Enrichment is asynchronous — the request returns as soon as the work is queued. Progress is visible as a live queue count, and the workspace reports itself idle once everything has drained. Each wallet’s last_enriched_at advances when its refresh completes, so you can also tell per wallet.
Enrichment jobs are deduplicated per wallet and chain, so enqueuing the same wallet twice in quick succession won’t double-spend credits.

Cost and limits

Enrichment consumes GoldRush credits — roughly 4 per wallet (it makes four data calls: balances, transactions, NFTs, and portfolio). Credits are a monthly allowance that scales with your plan: Once the allowance is exhausted, new enrichment is blocked — the SQL editor and your already-enriched data keep working. On Pay as you go, enrichment draws from your balance rather than a monthly allowance. Responses are cached per organization — 5 minutes for transactions, 10 for balances and portfolio, 15 for NFTs — so repeated enrichment of the same wallet within those windows is served from cache and doesn’t re-spend credits (unless you pass forceRefresh).

Using enriched data

Query it in SQL

user_onchain_metrics, wallet_activity_summary, nft_holdings, and the joined contact_360 view.

Build audiences

Whales, dormant holders, high-LTV wallets — save any query as a segment.

Score and prioritize

Engagement score feeds contact health and churn signals.

Personalize messages

Reference wallet traits as merge variables in campaigns.
The most common starting point is a query against contact_360, where enrichment is already joined to identity and email engagement:
Campaign merge variables for on-chain fields (like portfolioValueUsd) render from contact metadata, not directly from the enrichment tables. The enrichment tables feed analytics and segmentation through contact_360; for per-recipient personalization, the value needs to be present in the contact’s metadata.