Blog
In this blog, we introduce our latest API addition the Address Metadata Endpoint, a powerful API designed to provide comprehensive, real-time insights into blockchain addresses. Building on our previous advancements in on-chain data processing, this tool offers detailed metrics such as address type, interaction history, transaction data, and DeFi information.
In our previous blog posts, we covered the evolution of our on-chain data processing infrastructure, from optimising block data retrieval with NFS in On-Chain Series IV to leveraging Azure's L-Series machines for efficient processing in On-Chain Series V. These advancements have set the stage for our latest offering: the Address Metadata Endpoint. This endpoint provides comprehensive insights into blockchain addresses, serving as a cornerstone for future developments. In this post, we'll explore the capabilities of the Address Metadata Endpoint, how it integrates with our infrastructure, and why it's an essential tool for developers, analysts, and other blockchain users. Additionally, we'll discuss why we built this endpoint and how it's already being used internally to streamline our operations.
The Address Metadata Endpoint is an API that delivers real-time detailed metrics on specific blockchain addresses. Users can specify the blockchain asset (e.g., Ethereum) and the address of interest to access a wide range of data, including:
This endpoint is a practical and reliable tool for analysing address-level activity and attributes, built on the foundation of our robust data processing infrastructure.
To deliver consistent sub-50ms response times while maintaining 99.95% availability, we've implemented a resilient architecture that prioritizes both performance and reliability.
Our system employs a unique dual-Redis approach:
Redis Cluster: Our sharded Redis cluster serves as the primary data store for API access. This cluster is directly accessible by all API nodes, enabling horizontal scaling and load distribution. The cluster uses consistent hashing to partition addresses across multiple nodes, ensuring even data distribution and parallel query processing.
Local Redis on Processing VM: The VM that processes blockchain data maintains its own local Redis instance. This serves a critical purpose: redundancy. If the Redis cluster experiences issues or becomes unavailable, the processing VM can continue to function independently, ensuring zero data loss and continuous operation. This local Redis acts as both a working cache during processing and a failsafe that can resync with the cluster once connectivity is restored.
// Our redundant write pattern
const updateAddressMetadata = async (addressKey, metadata) => {
// Write to local Redis first (always available to the processing VM)
await redisLocal.set(addressKey, metadata);
// Sync to cluster for API access
try {
await redisCluster.set(addressKey, metadata);
} catch (error) {
// If cluster is unavailable, processing continues
// Data will be synced when cluster recovers
logModule.toConsole('Cluster sync failed, will retry', logModule.WARNING);
}
};While Redis handles active data, we use Cloudflare R2 for efficient long-term storage. Our intelligent archiving system continuously monitors Redis memory usage and automatically migrates inactive addresses to R2 when memory usage exceeds 70%. This approach allows us to:
When an address becomes active again after being archived:
const restoreAddressFromArchive = async (addressKey) => {
// Fetch from R2
const archivedData = await r2Client.get(`addresses/${addressKey}.json.gz`);
const metadata = JSON.parse(await gunzip(archivedData));
// Restore to both Redis instances
await redisLocal.set(addressKey, metadata);
await redisCluster.set(addressKey, metadata);
return metadata;
};Our system processes every Ethereum block sequentially, extracting and updating address metadata from:
The processing pipeline is designed for resilience:
The Address Metadata Endpoint was born out of our need to simplify and automate the mapping and discovery processes associated with blockchain assets. Historically, we've built our infrastructure to meet our own internal needs first — ensuring that every tool we develop is battle-tested and ready for real-world application.
When evaluating existing solutions from other on-chain data providers, we conducted a thorough investigation and found that none of them fully met our stringent standards for quality, accuracy, and comprehensive data coverage. The available endpoints either lacked the depth of information we required, couldn't handle the scale we needed, or didn't provide the reliability our systems demand. Given these limitations, we made the decision to build our own solution. This allowed us to maintain control over the data quality, ensure it met our specific requirements, and provide a tool that not only supports our internal operations but also offers unmatched value to our customers.
Asset Metadata Platforms: Within our asset manager platform, we leverage the Address Metadata Endpoint to streamline and enhance the accuracy of listing assets and their supported platforms. When our content team adds a new token, they simply input the contract address, and our system automatically populates:
This automation reduced asset listing time from 10+ minutes of manual research to under 30 seconds.
Exchange Reserve Tracking: One of the most critical applications is monitoring exchange solvency. By tracking all addresses associated with an exchange—from hot wallets to cold storage—we maintain real-time visibility into their reserves. This capability has become essential for:
The redundant architecture ensures this critical monitoring continues even during infrastructure maintenance or partial outages.
One of our key innovations is automatic token standard detection during contract deployment. When processing transactions, we analyze the input data against known function selectors:
// Detecting token standards in real-time
const detectTokenStandards = (transaction) => {
const standards = [];
if (containsSelectors(transaction.INPUT, ERC20_SELECTORS)) {
standards.push('ERC20');
// Batch fetch token details via RPC
const details = await rpcProvider.multicall([
contract.name(),
contract.symbol(),
contract.decimals(),
contract.totalSupply()
]);
metadata.TOKEN_DETAILS = details;
}
if (containsSelectors(transaction.INPUT, ERC721_SELECTORS)) {
standards.push('ERC721');
}
return standards;
};This automatic detection ensures we capture token metadata at deployment time, providing historical accuracy that post-hoc analysis often misses.
Our production environment demonstrates the effectiveness of this architecture:
The redundant architecture has proven invaluable during:
While the current Address Metadata Endpoint provides comprehensive activity and contract information, we're excited about our next major enhancement: real-time balance tracking.
Our upcoming release will extend the endpoint to include:
This enhancement will leverage our existing infrastructure—the same redundant Redis architecture and R2 archival system will efficiently store and serve balance data. By tracking balance changes at the transaction level during our block processing, we'll provide accurate, real-time balance information without the need for expensive on-demand RPC calls.
The architecture is already battle-tested; we're simply extending our data model to capture this additional dimension of address activity. This will transform the Address Metadata Endpoint from a powerful analytical tool into a complete address intelligence platform.
While Ethereum is our flagship implementation, we're actively processing and indexing address metadata for:
Each blockchain maintains its own local Redis and processing VM but they all share the same Redis Cluster, ensuring isolated failure domains while sharing our proven architectural patterns. This design choice brings significant advantages at the API level:
Unified API Access: By using a shared Redis cluster, our API nodes can query data from any blockchain without needing to know which processing VM handles that chain. This dramatically simplifies our API architecture—a single connection pool to the Redis cluster provides access to all blockchain data.
Cross-Chain Queries: The shared cluster makes it trivial to implement cross-chain features. Want to check if an Ethereum address has activity on BSC or Arbitrum? It's a simple multi-key lookup in the same cluster, no complex routing required.
Operational Efficiency: Instead of managing separate clusters per blockchain, our ops team maintains one highly-available Redis cluster. This reduces operational complexity while maintaining the isolation benefits—if Bitcoin's processing VM fails, it doesn't affect Ethereum data availability in the cluster.
Consistent Performance: All blockchains benefit from the same optimized Redis cluster configuration, ensuring uniform sub-50ms response times regardless of which chain you're querying. The cluster's consistent hashing automatically distributes load across nodes, preventing any single blockchain from creating hotspots.
Our focus on redundancy extends beyond just Redis:
2/blocks/19234567.json.gz), individual transactions by hash (2/transactions/0x5d2c...b111.json.gz), and address metadata archives work together to provide complete data lineageThis belt-and-bracers approach ensures that the Address Metadata Endpoint remains available even when multiple components fail simultaneously. The complete blockchain archive in R2 means we can always reconstruct any data point from source, providing the ultimate safety net for our services.
Integration is straightforward via our RESTful API: GET https://data-api.coindesk.com/onchain/v1/address/metadata/2?address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
{
"Data": {
"TYPE": "1927",
"ADDRESS": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"ADDRESS_TYPE": "CONTRACT",
"FIRST_INTERACTION_BLOCK_NUMBER": 4719568,
"FIRST_INTERACTION_BLOCK_TIMESTAMP": 1513077455,
"FIRST_INTERACTION_TRANSACTION_HASH": "0xb95343413e459a0f97461812111254163ae53467855c0d73e0f1e7c5b8442fa3",
"FIRST_INTERACTION_ADDRESS": "0x4f26ffbe5f04ed43630fdc30a87638d53d0b0876",
"LAST_INTERACTION_BLOCK_NUMBER": 22655012,
"LAST_INTERACTION_BLOCK_TIMESTAMP": 1749327083,
"LAST_INTERACTION_TRANSACTION_HASH": "0xc647d701a72fb664df8060ced9b9f09908b5063682cefbdf96a0240d179e76da",
"LAST_INTERACTION_ADDRESS": "0x0a9bc3b0d19bca983cd9a6d251dc5920e87b223e",
"FIRST_RECEIVED_TRANSACTION_BLOCK_NUMBER": 4719568,
"FIRST_RECEIVED_TRANSACTION_BLOCK_TIMESTAMP": 1513077455,
"FIRST_RECEIVED_TRANSACTION_HASH": "0xb95343413e459a0f97461812111254163ae53467855c0d73e0f1e7c5b8442fa3",
"LAST_RECEIVED_TRANSACTION_BLOCK_NUMBER": 22655012,
"LAST_RECEIVED_TRANSACTION_BLOCK_TIMESTAMP": 1749327083,
"LAST_RECEIVED_TRANSACTION_HASH": "0xc647d701a72fb664df8060ced9b9f09908b5063682cefbdf96a0240d179e76da",
"TOTAL_RECEIVED_TRANSACTIONS": 19831957,
"TOTAL_INTERACTIONS": 19831957,
"FULLY_COMPATIBLE_TOKEN_STANDARDS": [
"ERC20"
],
"ADDRESS_NAME": "Wrapped Ether",
"ADDRESS_SYMBOL": "WETH",
"DECIMALS": 18,
"SUPPLY_BURNT": 0,
"SUPPLY_CIRCULATING": 2.764409186177725e+24,
"SUPPLY_FUTURE": -1,
"SUPPLY_ISSUED": 2.764409186177725e+24,
"SUPPLY_LOCKED": 0,
"SUPPLY_MAX": -1,
"SUPPLY_STAKED": 0,
"SUPPLY_TOTAL": 2.764409186177725e+24
},
"Err": {}
}Behind this simple API lies our resilient infrastructure, automatically routing requests to healthy Redis nodes and seamlessly handling any infrastructure hiccups.
The Address Metadata Endpoint represents our commitment to building infrastructure that doesn't just work—it works reliably at scale, even when things go wrong. By architecting for redundancy from day one, we've created a system that our internal teams trust for mission-critical operations like exchange monitoring and risk analysis.
With our upcoming balance tracking features and continued expansion to new blockchains, we're excited to provide the blockchain community with the same level of reliability and performance that powers CoinDesk Data's internal operations.
Disclaimer: Please note that the content of this blog post was created prior to our company's rebranding from CCData to CoinDesk Indices.
Get our latest research, reports and event news delivered straight to your inbox.
.png)
.avif)
.avif)
