Service · Remote-first senior specialists
Raw chain data is not analytics. MV.tech decodes transactions, logs and events using contract ABIs and Web3.py, consolidates them across networks into BigQuery, and adds the valuation, categorisation and reconciliation layers that let finance, product and compliance teams answer questions about on-chain activity.
The starting point
What we deliver
Pull blocks, transactions, logs and events from node RPCs, indexers and chain APIs into a common schema in BigQuery. Reorg handling, backfills, checkpointing and per-chain rate limits are part of the pipeline rather than an afterthought. Work has covered Ethereum, Bitcoin, Immutable X, Immutable zkEVM, XDC, WEMIX, Tezos and Cardano.
Apply contract ABIs with Web3.py to turn opaque input data and topics into named events with typed arguments: transfers, mints, burns, stakes, swaps. That includes proxy contracts, non-standard implementations and the contracts whose interface has to be reconstructed before anything can be read.
Maintain token registries and price reference data, and value movements at the relevant block timestamp in the reporting currency, handling decimals, fee proration and FX explicitly. Widening mapping coverage is ordinary, high-value work: on past engagements it moved from 35 tokens to 42 and beyond, pulling material volume out of the unknown bucket.
Classify activity into the categories the business reports on — transfer, trade, fee, reward, bridge, internal movement — using contract, method, counterparty and pattern rules that are written down and reviewable rather than buried inside a query.
Reward ledgers per validator, delegator or wallet, reconciled against on-chain distributions and internal records, with period totals, accrual timing and a discrepancy report. On past engagements a ledger of this kind has removed more than 70% of a manual reconciliation cycle.
Wallet-level histories, balances over time, cohort and retention views, and attribution of addresses to known entities or internal accounts, with the labelling maintained as data rather than hardcoded into reports.
Queryable datasets for investigation and monitoring: counterparty exposure, flows through addresses of interest, thresholds and time-windowed aggregates. They support an analyst’s judgement and an auditor’s questions; they do not replace either.
Base tables hold exactly what the chain reported and are never edited. Manual corrections, whitelists and overrides live in separate layers applied when the reporting view is built, each carrying an author, a timestamp and a reason, so a figure can still be explained months later.
A useful first project
Take a single network and one business question — a quarterly token flow, a staking-reward total, a wallet cohort — and build it the whole way: ingestion, decoding with the relevant ABIs, token mapping, valuation, categorisation and a reconciled output compared against whatever figures exist today. One chain done properly establishes the schema, the decoding patterns, the override model and the validation checks, so the second and third networks are mostly configuration rather than new engineering.
See our delivery processWorking together
Identify the networks, contracts and wallets in scope, the reporting currency and period, and the figures the output has to reconcile against.
Build the pipeline and decoding layer, map tokens, apply valuation and categorisation, and check coverage and gaps block by block.
Compare against on-chain and internal sources, document the override path, then schedule, monitor and hand over with the mapping rules.
Teams our engineers have worked with
Before we begin
Not answered here? Ask us directly or read the full FAQ.
Public datasets are a reasonable starting point for common chains and standard token transfers. They tend to fall short on newer or smaller networks, on contracts whose events are not standard, and on the business layer: your token registry, your categorisation rules, your reporting currency and your reconciliation against internal records. We use public datasets where they fit and build ingestion where they do not.
Several ways, in order of preference: a verified ABI from the explorer, a standard interface the contract conforms to, an ABI supplied by whoever deployed it, or reconstruction from method signatures and observed event topics. Whichever route is used, the decoding rules are recorded per contract and the raw input data is retained, so decoding can be corrected and replayed without re-ingesting the chain.
That is what the override layer is for. Base tables hold what the chain reported and are never edited. Corrections, whitelists and manual classifications live in separate tables with an author, a timestamp and a reason, and are applied when the reporting view is built. Both the original and the adjusted figure stay available, which is usually what an auditor asks to see.
Carefully, and visibly. The valuation method is a documented rule per token: reference price at block timestamp, a defined source hierarchy, a fallback, or explicitly no valuation at all. Unvalued volume is reported rather than hidden. It is better for a finance team to see that a share of activity has no reliable price than to receive a confident number built on a thin market.
Yes. On-chain data is just another source: it lands in the same layered warehouse, under the same validation and modelling standards, and is read by Power BI, Looker Studio, Tableau or a Streamlit tool alongside everything else. Teams usually want it joined to off-chain records — customers, internal accounts, fiat movements — and that join is where most of the analytical value appears.
Related services
ETL/ELT pipelines, BigQuery, Snowflake and Redshift warehouses, migrations, semantic models and reporting your team can trust.
ExploreDedicated offshore data engineering and analytics capacity from India for ETL, cloud warehouses, BI, migration and data quality work.
ExploreKnowledge assistants grounded in your documents, MCP servers and custom connectors exposing approved tools, and LLM features with evaluation built in.
ExploreYour next step
Bring your goal, current tools and preferred working hours. We use the first 30-minute conversation to clarify fit and an initial scope, and you leave with a written next step.
Remote from Ahmedabad, India · Overlap with any timezone · No obligation
