Indexed PlumeBlockchain Data

Plume is an EVM Layer 2 whose mainnet went live in 2025, built on the Arbitrum Orbit stack and settling to Ethereum. Execution is ordinary EVM: Solidity contracts, twenty-byte addresses, receipts and event logs in the shapes an EVM pipeline already reads. What is not ordinary is what gets deployed on it. Plume was built for tokenized real-world assets, so a large share of its token contracts are permissioned: they check eligibility before a transfer settles, and the issuer keeps powers an ordinary ERC-20 does not grant, including pausing, freezing, forced redemption and minting against an offchain event. PLUME is the network’s token. Valuations and attestations about the underlying assets are published onchain as contract writes, which means a figure recorded here is a stated value with a timestamp rather than a market quote.

SonarX indexes Plume end to end: blocks and headers, transactions and receipts, event logs decoded against contract ABIs, execution traces including internal value transfers, and token transfers and balances. The same normalized model is used on every chain SonarX covers, so a tokenized position here joins to holdings elsewhere without a translation layer.

Full historical coverage is provisioned for Plume on request. Balance tables and the balance APIs can be enabled for Plume on request. Kafka streaming can be enabled for Plume on request.

Transfer events do not tell the whole story of who owns what on this chain. Ownership also changes through issuer actions, so mints against a subscription, freezes, forced redemptions and pauses have to be decoded and carried alongside transfers or a holder register drifts from reality within weeks. Those contracts are usually upgradeable, so decoding follows the implementation behind the proxy rather than the address that emitted the log, and a change of implementation mid-history changes the event vocabulary without changing the address. Attempted transfers that revert on an eligibility check matter too: a rejection is evidence about a holder, not an absence of activity.

The work here looks like asset servicing rather than like crypto analytics. Holder registers come first: who held which instrument at which block, restated as at a reporting date and reconciled against the issuer’s own record. Distribution accounting is the second, following coupon, yield or redemption payments from the contract that released them to the accounts that received them. Audit trails are the third, since a supervisor asking why an account could not receive a token wants the eligibility check that rejected it, not a summary. That work is what RWA and tokenization analytics cover across every chain SonarX indexes, and teams comparing issuance venues usually pull MANTRA alongside this one.

Tell us the delivery target, how far back you need and how fresh it has to be, and the share is scoped against that. Plume coverage is provisioned on request, so tell us the history depth and the delivery target and we will scope it. 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.