HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Products & integrations

Which integration patterns are shared, and which remain chain-specific?

3 min read

Product discovery, scoped access, and retained evidence provide common integration concepts. Address formats, asset identifiers, finality rules, enabled routes, and signing requirements still need chain-specific handling.

Reuse the concepts that really are common

Applications can use consistent ways to identify a user, describe a requested operation, show a status, and link evidence. This can reduce duplicated interface work and help operators learn one understandable pattern. A support screen might always show the resource, network, recorded time, and next supported action. Such consistency is valuable when the underlying data remains accurately labeled rather than being forced into a misleading common meaning.

Keep chain-specific facts explicit

Address formats, token identifiers, fee currencies, and confirmation rules can differ. The same word, such as “confirmed,” may not describe the same level of finality on every network. Keep the raw network context and relevant evidence available to the application. Use a translation layer for readable wording, but do not discard distinctions that affect whether value arrived or an operation is authorized. A common interface should explain differences, not erase them.

Test the shared component against real variations

Try a pending record, a missing external reference, a token fee paid in another currency, and an unavailable route where your test scope permits. Verify that the screen remains accurate and the user is not offered an unsupported action. Keep network-specific requirements close to the operation contract. This gives engineering a reusable foundation while giving business users a truthful explanation of what happened on the particular chain they selected.

Illustrative example

A shared activity screen displays a consistent status layout while linking each record to the correct network evidence.

In plain language

The network is part of the address and asset

A currency symbol is a convenient label, not a complete destination. Two networks can use similar-looking addresses, and tokens with the same ticker can exist on more than one chain. The safe description includes the asset, its network, and any chain-specific token identifier, as well as the recipient address. Mainnet, Testnet, and Devnet are also separate contexts: a test balance is not a production balance simply because both screens show a familiar name. Before any external transfer, obtain the receiving details from the intended, authorized wallet workflow and compare the network at both ends. Do not choose a different network just because it appears cheaper without confirming the whole route. A shared application can make these choices easier to manage, but it cannot erase the differences between the underlying chains. If the destination or route is unclear, stop before authorizing the transfer and ask for clarification.

In plain language

What an API contract tells your team

An API is a way for one application to ask another system for information or an action. The operation contract is the detailed description of that particular request: what information to send, what access is required, what a response means, and which errors can occur. It is more precise than a product overview. A read normally retrieves information; a write can create or change something and therefore needs more careful handling. Developers should use the current contract for the deployed environment rather than guessing from a similar endpoint or an old example. Business users can help by stating the outcome in ordinary language and naming who may authorize it. Both sides should agree how to identify the request later, what happens if a response is delayed, and which record establishes completion. These details turn a demonstration into an integration that people can operate responsibly.

Conditions & limitations

Do not normalize away a chain distinction that changes transaction meaning or authority.

What to do next

Keep network and operation context explicit in your data model and test each supported combination.

Developer portal ↗Wallet evaluation framework ↗