Indexed MANTRABlockchain Data

MANTRA has produced blocks since its October 2024 genesis, on a chain identified as mantra-1, and it was built for tokenized real-world assets rather than for general-purpose applications. Validators run CometBFT under proof of stake, OM is the native token written amantra at eighteen decimals, and accounts use Ethereum-style keys, so one holder has a mantra bech32 address and a twenty-byte hex address at the same time. The v5 upgrade added an EVM module, so Solidity contracts now run beside the chain’s own. What separates it from its neighbors is that regulatory machinery sits in the protocol. Tokens are created through a factory that keeps an administrator, a transfer can be taxed by the chain itself, and governance can sanction an address, which means an issued asset can be restricted to accounts that meet an issuer’s rules without anyone writing a custom contract.

SonarX indexes the chain and both of its execution surfaces: blocks and transactions with their typed messages, factory token creation and administrator actions, taxed transfers, sanctions, EVM transactions with receipts and logs decoded against contract ABIs, staking and governance records, IBC transfers, and derived balances. It is all normalized into the model SonarX uses across every network it covers, so positions here compare directly with those on Provenance.

Full historical coverage is available today as a data-share or a file delivery. Real-time delivery is enabled on request. Balance tables and the balance APIs can be enabled for MANTRA on request.

Policy is why this chain’s records do not read like an ordinary token history. A transfer can be reduced by a protocol-level tax, so debit and credit need not match and the cut has to be derived from the difference rather than read as a payment. A sanctioned address turns a valid-looking send into a rejection, which makes failures informative instead of noise. Factory tokens keep an administrator who can mint, so supply moves without a contract emitting anything. And one key arriving as bech32 and as twenty bytes has to be resolved before a holder count means anything.

Holder and eligibility analysis is the first workload: who was permitted to hold an issued asset, when that changed, and which accounts were restricted. Supply accounting is the second, because an administrator can mint or burn a factory token and circulating supply has to net those actions against transfers. Period-end reporting is the third, reconstructing positions at a date for a fund or an issuer. Settlement tracing is a fourth, following the dollars that arrive from Noble against the assets they bought. RWA and tokenization work covers this shape of analysis across chains.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. MANTRA history is available now, so a first delivery is provisioning rather than engineering. The published coverage matrix for every network SonarX indexes lives in the data documentation, and the rest of the catalogue is at all indexed chains.