Overview
dApp Activity rules let you incentivize smart contract deployers by ranking their contracts on a chosen on-chain metric and distributing rewards based on rank tiers. This is designed for networks and ecosystems that want to drive developer engagement and reward the dApps that contribute the most on-chain activity.
Rewards go to the deployer wallet — the address that originally deployed the smart contract. If a single deployer has multiple contracts that rank within your configured tiers, their rewards are aggregated across all qualifying contracts into a single payout.
Rule types
There are four rule types, each ranking dApps by a different metric:
| Rule type | Metric | What it measures |
|---|
| dApps by Gas Spent | Total gas consumed | Rewards dApps generating the most computational activity on the network |
| dApps by Active Users | Unique active wallets | Rewards dApps with the highest number of unique interacting wallets |
| dApps by New Users | New unique wallets | Rewards dApps attracting the most first-time users |
| dApps by Transaction Count | Total transactions | Rewards dApps with the highest transaction throughput |
All four rule types share the same configuration flow, scheduling options, and reward logic — they only differ in which on-chain metric is used for ranking.
Availability and enablement
- Availability: dApp Activity rules are available to enterprise partners.
- Network support: Currently available on EVM-compatible chains. We add new blockchain support upon request, so please reach out to Snag if you need this configured for a specific chain.
How it works
- Data collection — Snag’s analytics service continuously indexes on-chain activity (gas usage, unique wallets, transactions) per smart contract on supported chains.
- Ranking — When the rule executes, it fetches the top contracts for the selected chain and metric, filtered by the configured data window and optional deployment recency filter.
- Tier matching — Each ranked contract is matched against your configured reward tiers. A contract’s rank determines how many points (or which badge) its deployer receives.
- Aggregation — If a deployer has multiple contracts in the ranking, the rewards from all their qualifying contracts are summed into a single payout to the deployer wallet.
The data window always covers full completed days — it starts from the end of the previous day (midnight UTC) and looks back. For example, if a rule with a weekly data window runs on March 15th, the period analyzed is March 7th – March 14th (7 full days). The current day (March 15th) is not included because it is not yet complete.
Claim types
dApp rules support two claim modes:
| Mode | Behavior |
|---|
| Auto | The rule runs on its configured schedule (daily, weekly, or monthly). Snag’s backend automatically fetches the leaderboard, calculates rewards, and distributes them to all qualifying deployer wallets — no user action needed. |
| Manual | Deployers visit your loyalty page and trigger a claim themselves. When they do, the system looks up contracts deployed by their connected wallet, checks the current leaderboard, and distributes any earned rewards on the spot. |
Configuration
Network
Select the EVM chain to analyze. The rule will rank contracts deployed on this specific network.
Data window
Controls which time period of on-chain data is used when building the leaderboard. This is required.
| Option | Time range |
|---|
| Last 24 hours | Activity from the past 1 day |
| Last 7 days | Activity from the past 7 days |
| Last 30 days | Activity from the past 30 days |
Choose a data window that matches your reward cadence. For example, pair a weekly data window with a weekly schedule so each run covers a fresh, non-overlapping period of activity.
Deployed within
Filters which contracts are eligible based on when they were deployed.
| Option | Eligibility |
|---|
| Any | All contracts are eligible regardless of deployment date |
| Day | Only contracts deployed in the last 24 hours |
| Week | Only contracts deployed in the last 7 days |
| Month | Only contracts deployed in the last 30 days |
Reward tiers
Define how rewards are distributed based on ranking position. Each tier specifies a start rank, end rank, and reward amount. You can configure multiple tiers for a graduated reward structure.
Example configuration:
| Rank range | Reward per contract |
|---|
| 1 – 10 | 1,000 points |
| 11 – 50 | 500 points |
| 51 – 100 | 100 points |
Frequency
Controls how often deployers can earn rewards from this rule, regardless of whether the claim type is auto or manual.
| Option | Behavior |
|---|
| Daily | Deployers can be rewarded once per day |
| Weekly | Deployers can be rewarded once per week |
| Monthly | Deployers can be rewarded once per month |
Best practices
- Align data window and frequency — If the frequency is weekly, use a weekly data window so each cycle covers fresh data without overlap or gaps.
- Set realistic tier boundaries — Consider how many active contracts exist on the target chain. Setting a tier that ends at rank 1,000 on a chain with 50 active contracts means most of that tier goes unused.
- Combine with manual claims for user engagement — Auto rules are hands-off, but manual claims drive users to your loyalty page and increase engagement touchpoints.
- Use graduated tiers — Rather than a flat reward for all ranked contracts, create multiple tiers with decreasing rewards to disproportionately incentivize top performers.
Troubleshooting
| Symptom | Likely cause | Resolution |
|---|
| Manual claim says “No eligible dApps found” | The connected wallet hasn’t deployed any contracts on the selected chain within the configured windows | Verify the wallet address and that the contract was deployed on the correct network |
