Gaming Activity

- Includes general in-game interactions such as daily logins, battles, and quests.

- These events have high user counts (`N_USERS`) and frequent transactions (`N_TXNS`).

Item Trading

- Covers the minting, trading, and burning of in-game assets.

- Data shows a substantial number of transactions related to NFT/game asset exchanges.

Token (Staking, Rewards)

- Includes financial incentives such as staking rewards and liquidity provisions.

- These events exhibit relatively high transaction volume but a lower unique user count compared to gaming activity.

Asset Transfer

- Represents wallet-to-wallet transactions, approvals, deposits, and withdrawals.

- High transaction count but may involve fewer unique users compared to gameplay activities.

Social & Guild Interactions

- Captures community-driven activities such as joining guilds, making friends, and leaderboard updates.

- Moderate transaction count but strong user engagement, crucial for multiplayer experiences.

Quest & Battle Participation

- Focused on competitive and cooperative engagements, including PvP battles, custom bets, and mission completions.

- Shows high user engagement (`N_USERS`) and is often correlated with reward distributions.

Marketplace Activity

- Includes actions related to in-game economies such as item listings, auctions, and product purchases.

- High transaction volume but limited unique users due to the nature of market participation.

Burn & Sync Mechanics

- Represents token deflation mechanisms where in-game assets are burned or upgraded.

- Lower transaction counts but significant for game economy balancing.

When analyzing on-chain gaming activity, both unique users (N_USERS) and transactions (N_TXNS) provide essential but distinct insights:

1️⃣ Unique Users (N_USERS): Measures Breadth of Participation

• Represents how many individual wallets engaged with an event.

• A high number of unique users means broad participation, indicating mass adoption and strong engagement.

2️⃣ Transactions (N_TXNS): Measures Depth of Engagement

• Reflects how frequently an event occurs.

• A high transaction count means users interact often, which may suggest:

  • Strong engagement (Gaming Activity, Marketplace)

• A low transaction count means users interact infrequently, which may suggest:

  • One-time actions (Minting, Guild Join)

Cap Minimum Unique Users at 500 and Above

1. To remove statistical noise and anomalies, we cap the minimum unique users (N_USERS) to 500. This ensures that our analysis focuses on significant trends rather than edge cases.
   

   📌 Reasons for the 500-User Threshold
   

   1. Filters Out Low-Signal Events

      • Events with fewer than 500 users might be test transactions, niche features, or special cases.

      • Example: A smart contract function used only by developers/admins.

   2. Ensures Statistical Relevance

      • Small sample sizes can skew recurrence rates and category weighting.

      • A 500-user minimum ensures our analysis reflects broader game economy trends.

Recurrence rate provides insights into user behavior across different event categories.

It tells us how frequently a user engages within a category, which directly impacts the importance of that category in the ecosystem.

The Referral event has a recurrence rate close to 1.0, meaning users typically engage with it only once.

- This suggests referral-based actions are one-time engagements, possibly tied to onboarding incentives or limited-time promotions.

- All other event categories have a recurrence rate > 1.0, meaning users interact with them multiple times.

• NFT Smart Contracts with NULL Events:

  • If an NFT contract has a NULL EVENT_NAME, it suggests that tradable gaming assets (NFTs) do not emit named events and can only be analyzed via nft_transfers activity.

• Token Contracts Reflect Tradable Assets via "Transfer" Events:

  • The majority of token contracts emit a Transfer event, reinforcing that fungible gaming assets (such as SLP and AXS) primarily move through direct transfers.

• NFT Contracts with Event Names Indicate In-Game Activity:

  • Some NFT contracts do have EVENT_NAME:AxieLevelUpdated, AxieEvolved, which might represent in-game mechanics such as breeding, crafting, or usage of NFTs within the game.

P.S. address_labels successfully captured 100% of Axie Infinity's onchain contracts. ✅ [Verified]

1. Game Contracts (Marketplace & In-Game Transactions)

• Key Events: OrderMatched, OrderCancelled

• Findings:

  • OrderMatched (1.2M+ transactions, 70K+ users).

  • OrderCancelled (1.2M+ transactions, 37K+ users).

2. NFT Contracts (In-Game Asset Transfers)

• Key Events: NonceUpdated, Transfer, ApprovalForAll, PermissionSetAll, AxieLevelUpdated

• Findings:

  • NonceUpdated (2.5M+ transactions) is the most recurrent event, possibly related to smart contract security measures or replays.

  • Transfer (2.4M+ transactions) aligns with tradable assets moving between players.

  • ApprovalForAll (130K+ transactions) suggests that players delegate NFT control, possibly for automated breeding or renting.

  • AxieLevelUpdated (288K+ transactions) indicates an upgrade mechanism where Axies level up, confirming on-chain progression.

3. Token Contracts (Fungible Assets)

• Key Events: Transfer, Approval, Withdrawal, Deposit, Upgraded

• Findings:

  • Transfer (11.9M+ transactions, 540K+ users) is the dominant event, proving active movement of tokens like SLP and AXS.

  • Approval (1M+ transactions) suggests frequent delegation for token spending, often seen in DeFi.

  • Withdrawal and Deposit (~900K transactions each) highlight a bridge or exchange mechanism moving tokens between wallets and possibly centralized platforms.

  • Upgraded (3 transactions) is rare, likely an experimental feature or an administrative upgrade.

• Filtering Out Low-User Events
  Events with fewer than 500 unique users have been removed. This helps eliminate noise and anomalies, ensuring that we focus on meaningful trends rather than edge cases.

• Utilizing Labeled Contracts
  The 18 events detected under labeled contracts in ronin.core.dim_labels have been analyzed to identify their associated event names. This gives us better insights into their function and relevance within the ecosystem.

• Tradable NFTs Lack Event Name Associations
  Actual tradable NFTs do not have specific event names associated with them. Instead, they only appear in the nft_transfers table, which suggests that direct trading of NFTs does not trigger distinct contract events in the dataset.

• NFT-Labeled Contracts Are Primarily for In-Game Activity
  NFT-related contracts that do have event names are mostly linked to in-game activities or the transfer of game assets rather than direct marketplace transactions. This reinforces the idea that gaming ecosystems have unique asset flows separate from standard NFT trading.

• Unlabeled High-User Events Still Exist
  Even after filtering, there are still event names (49 of them) with 500+ unique users that do not yet have labeled contracts. However, after manually identifying the contracts that called these event functions, we now have visibility into contract names, allowing us to further categorize them into distinct subsets for deeper analysis.

• Gaming Contracts Tend to Be More Focused
  Events tied to just one smart contract are often linked to gaming activities. This suggests that many gaming projects rely on single-purpose contracts that handle specific functions, unlike DeFi protocols, which tend to be more complex.

• Liquidity-Related Events Have a Clear Pattern
  Events like Sync, Mint, Swap, and Burn almost always involve multiple smart contracts. This makes sense since these events are essential to token liquidity and trading, especially within DEXs and AMM protocols. The more smart contracts involved, the more likely the event is tied to managing liquidity pools.

• Contract Names Help Categorize On-Chain Activity
  By mapping event names to the contracts that trigger them, we now have a clearer way to group events into meaningful categories. This is particularly useful for distinguishing between trading-related actions, gaming interactions, and system-level operations.

This table lists events with more than 500 unique users, where the contract addresses triggering these events are not labeled. To address this, we manually identified the contracts behind these events. By analyzing the contract names associated with each event, we can further categorize them into relevant groups, providing better insights into their function and significance.

This table displays all events linked to the labeled contracts in ronin.core.dim_labels, where each event has more than 500 unique users.

Overview

The categorization methodology was designed to analyze blockchain events on the Ronin network and classify them into three main categories:

1. Game Activity: Events related to gaming interactions

2. NFT Transfers: Events related to transferring non-fungible tokens

3. Trades: Events related to token swaps and economic activities

Data Sources

The analysis utilizes four primary data sources from the Ronin blockchain:

1. dim_labels: Contains contract labeling information indicating contract types (NFT, token, games)

2. ez_decoded_event_logs: Contains decoded events from contract interactions

3. ez_nft_transfers: Contains specific NFT transfer events

4. Non-labeled contract mapping: Custom mapping for contracts without formal labels

Categorization Logic

1. Game Activity

Events are classified as Game Activity if they meet any of the following criteria:

• Associated with contracts labeled as "games" in dim_labels

• NFT-labeled contracts with specific gaming events:

  • AxieLevelUpdated

  • AxieEvolved

  • AxieMinted

  • BreedingInfoUpdated

• Events from game-related contracts identified in the non-labeled mapping:

  • Kalodium Gacha contracts

  • Duel Arena Escrow

  • Pixels Game Tracker

  • Wild Forest Signal Fire

  • Gold Rush contracts

  • Ronin Game Inbox Proxy

• Events with specific game-related names regardless of contract:

  • playedGacha

  • redeemedDaily

  • batchPlayedGacha

  • DepositLUAToGame

  • RoyalFavorCashIn

  • BoughtEnergy

  • Fire

  • DailyLogDone

  • ProductPurchased

  • Withdrawn/Deposited (from game escrows)

2. NFT Transfers

Events are classified as NFT Transfers if they meet the following criteria:

• Transfer or TransferSingle events from contracts labeled as "nft" in dim_labels

• Records from the ez_nft_transfers table associated with NFT-labeled contracts

3. Trades

Events are classified as Trades if they meet any of the following criteria:

• Associated with contracts labeled as "token" in dim_labels

• Events from trading-related contracts identified in the non-labeled mapping:

  • Katana Pair Proxy

  • Buy/sell token with ETH contracts

  • Burn Mint Token Pool

  • Affiliate Router

  • Token contracts (KALO, Kalodium)

• Events with specific trading-related names:

  • Sync, Mint, Swap, Burn (from DEX contracts)

  • Trade, FirstBuyerFeePaid, TokenCreated

  • kalodiumMinted, kalodiumBurnt

  • Burned, FeeTaken