Aptos NFTs KPI Dashboard
Aptos Token Standards The Aptos Digital Asset Standard defines the canonical Non-fungible Token on Aptos. Aptos leverages composability to extend the digital asset standard with features like fungibility via the Fungible Asset standard. The concept of composability comes from the underlying data model for these constructs: the Move object data model.
The rest of this document discusses how the Aptos token standards compare to the standards on Ethereum and Solana.
Data models To understand tokens, we begin by comparing the data models across different blockchains.
Ethereum Ethereum has two types of accounts:
Externally-owned accounts which store a balance of Ether. Contract accounts which manage their underlying smart contracts and have an associated storage for persistent state, which can only be mutated by the associated contract. In order to create a new NFT collection, a creator must deploy their own contract to the blockchain, which in turn will create a collection and set of NFTs within its storage.
Solana Unlike Ethereum or Aptos where data and code co-exist, Solana stores data and programs in separate accounts. There are two types of accounts on the Solana blockchain:
Executable accounts only store contract code Non-executable accounts store data associated with and owned by executable accounts. In order to create a new NFT collection, a creator calls an existing deployed program to populate a new collection and set of NFTs.
Aptos The accounts in Aptos store both smart contracts and data. Unlike Ethereum, the associated data of a smart contract is distributed across the space of all accounts in resources within accounts or objects. For example, a collection and an NFT within that collection are stored in distinct objects at different addresses with the smart contract defining them at another address. A smart contract developer could also store data associated with the NFT and collection at the same address as the smart contract or in other objects.
There are two means to create NFTs on Aptos:
The no-code standard allows creators to call into the contract to create new collections and tokens without deploying a new contract. Custom NFT contracts allow creators to customize their NFTs by extending the object model that can manage all aspects of their collection. Aptos strikes a balance between the customizability offered by Ethereum with the simplicity of creating new collections like Solana.
Like Ethereum, Aptos requires indexing to determine the set of all NFTs owned by an account, while Solana has no need.
To retrieve all these results, I utilized the 'aptos.core.fact_transactions' table. Most Common Table Expressions (CTEs) relied on the 'events' and 'payload' columns.
The steps I followed to write these queries are as follows: Initially, I examined transactions across different markets. Then, I used aptscan to inspect transactions. It provided a good structure, showcasing activities within the markets effectively.
Subsequently, I realized that by searching for 1 or 2 models of 'payload_function' in this blockchain, I could obtain all transactions. Hence, I employed the following query to find all available functions in a market:
SELECT DISTINCT payload_function , split_part(payload_function , '::' , 2) ,split_part(payload_function , '::' , 3) FROM aptos.core.fact_transactions WHERE payload_function ilike '0xe11c12ec495f3989c35e1c6a0af414451223305b579291fc8f3d9d0575a23c26%' -- Mercato
Later, with a query like:
SELECT * FROM aptos.core.fact_transactions a -- , LATERAL FLATTEN(input => parse_json(a.events)) f WHERE payload_function = '0x584b50b999c78ade62f8359c91b5165ff390338d45f8e55969a04e65d76258c9::collection_offer::cancel' -- AND tx_hash = '0xe551462e63941e9c29ec114bf8bf4de7cfdb3140273aee4f75775cc5dc3f323a' AND success LIMIT 1000
I randomly searched for more than 3 transactions on aptscan and retrieved necessary data by utilizing:
LATERAL FLATTEN(input => parse_json(a.events))
This was for the 'events' column and filtering f.value:type. For instance, using the query below, you can search for all individual secondary sales in the Wapal market:
normal_wapal_sale AS ( SELECT a.block_timestamp ,a.tx_hash ,f.value:data:purchaser AS buyer_address ,f.value:data:seller AS seller_address ,f.value:data:price/pow(10,8) AS amount ,'AptosCoin' AS token_symbol ,f.value:data:token_metadata:collection_name AS collection_name ,f.value:data:token_metadata:token_name AS item ,'Wapal' AS market ,'Sale' AS function FROM aptos.core.fact_transactions a , LATERAL FLATTEN(input => parse_json(a.events)) f WHERE f.value:type = '0x584b50b999c78ade62f8359c91b5165ff390338d45f8e55969a04e65d76258c9::events::ListingFilledEvent' AND payload_function = '0x584b50b999c78ade62f8359c91b5165ff390338d45f8e55969a04e65d76258c9::coin_listing::purchase' --AND tx_hash = '0x3a6d0023491da47ffedb001f3380679ef531fe4095d71399bd478dfe955a4094' AND success )
Similarly, I wrote queries for almost 80% of transactions possible in a market. I chose to use this column and the LATERAL FLATTEN command because individuals might purchase multiple NFTs within a transaction (Sweep). Using a different command might have merged purchased prices and items together
All the answers have been computed using 3 main queries, which are:
Note: For each CTE (Common Table Expression), a sample transaction has also been provided
. .
