Beyond EVM: Comparing Account, Object and UTXO Data Models
Build a shared data contract while preserving the differences between EVM, Solana, Move-based systems and UTXO networks.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
Multi-network applications often begin with a convenient schema: address, transaction, sender, recipient and value. That shape can help with one set of records, but it becomes ambiguous when applied without adjustment to networks organized around different account, object or output models.
A better shared contract starts from carefully defined concepts and leaves room for native context. The goal is predictable consumption, not identical-looking fields at any cost. This matters when adding a new network to a wallet, analytical export or financial-data workflow that already assumes a familiar transaction model.
Compare the record model before normalizing fields
List the native observations required by the application: accounts, objects, inputs and outputs, instructions, events or state references. Define what the consumer needs to know about each rather than starting from an existing frontend component's field names.
A transaction-level record can contain several relevant asset observations. An account relationship can mean a controlling program, a holder or another network-specific role. A shared value field needs both an asset identity and unit. Write examples from each intended network and identify which common concepts have the same meaning. Fields without compatible semantics should retain native context or an explicit unresolved interpretation rather than being populated with a convenient but misleading approximation.
Keep account and program relationships precise
An account-oriented system can still have several distinct meanings of ownership and control. Solana's account documentation is one reference for program ownership, while the Aptos account documentation describes its own account and resource context.
Do not assume that identical-looking owner fields describe equivalent relationships. Preserve the record type and relevant account roles. A synthetic comparison can include an ordinary account, a program-controlled account and an account with associated resources. The normalized view should explain which role a field represents, while the original account identifiers and observation references remain available to later consumers and revised interpretations.
Retain object identity and relevant versions
An object-oriented record can need an object identifier, version or other state context and a documented ownership relationship. Flattening it into a token balance can remove information required to explain which state was observed and how a later record relates to it.
The Sui object-model documentation provides a primary example of a different native model. A common application schema should preserve the relevant object context rather than implying every object has the same account-style lifecycle. Test an observation that changes version and one whose interpretation is unavailable. A later representation should be related to the earlier observation instead of being treated as an unexplained duplicate or replacement quantity.
Keep UTXO attribution separate from network structure
A UTXO-oriented record relates inputs to previously created outputs. Wallet-level sender and recipient labels are interpretations over that structure, often requiring declared wallet scope or additional evidence. Keep the underlying references available when presenting a concise activity item.
A synthetic transaction can contain several inputs and outputs, including one output attributed as change under an explicit test policy. The common view can show a wallet movement without inventing a universal single-sender network field. Preserve output positions, compatible integer quantities and attribution rules. This lets downstream consumers revise a wallet label while retaining the original evidence, and avoids confusing an external payment with every output created by the transaction.
Qualify assets and observations across namespaces
A shared identifier should retain the network namespace and relevant native reference. Account strings, token symbols and transaction-shaped values can collide across contexts. Do not use display labels as storage keys or cross-network deduplication criteria.
Retain the original representation and any documented canonical form. Lowercasing or shortening every account value can violate namespace-specific meaning. The CAIP-10 account specification provides a useful cross-network reference. Test the same display symbol and address-shaped string in several networks. They should remain distinguishable through queries, caches, exports and the interface, while any intentional application-level grouping retains the original qualified members and its own versioned interpretation rule.
Build a capability matrix and acceptance cases
Describe supported observation types, range boundaries, quantity representation and unresolved states separately for each network. A successful request to one chain does not establish equivalent capabilities on another. Keep common consumer expectations small enough to explain and validate.
Test native-model differences, unknown record types, partial network failure and repeat processing. Follow the records through every consumer, including CSV exports and mobile or cached views when relevant to the application. Useful normalization preserves meaning while reducing repetitive integration work. It gives a developer both a predictable common structure and the native references needed to investigate a surprising result, instead of forcing all records into one familiar but inaccurate transaction shape.
Questions about the topic
Frequently asked questions
Does JSON-RPC imply that two networks share a data model?
No. Transport and method encoding do not establish equivalent account, transaction or asset semantics. Check the native records and document the meaning of normalized fields.
Should every network use sender and recipient fields?
Only where those fields have a supported, clearly defined meaning. Preserve native relationships and explicit unresolved interpretations when a single-sender model would require guesses.
How can a multi-chain schema remain useful?
Use carefully defined common concepts, qualified identities and exact quantities, while retaining network-specific context. A capability matrix helps consumers handle differences and partial results deliberately.
Standards & technical documentation
