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

Products & integrations

Can we add wallet capabilities to an existing application?

3 min read

Use the wallet integration path to evaluate how your application discovers wallet context and presents authorized operations. This can keep your existing business experience while adding a clearly bounded wallet workflow.

Add a bounded wallet journey

An existing application can begin by discovering the permitted wallet context and displaying meaningful status. This lets the team learn the network and identity relationships before attempting a consequential action. Decide where the new experience belongs in the existing customer journey and what the customer must understand. A wallet panel should not suggest that funds can move merely because an identifier or balance can be read.

Do not confuse application login with wallet authority

Your application may know who is signed in, but the wallet operation can require additional customer authorization and readiness. Preserve those requirements rather than treating a successful login as permission to sign. Service credentials and customer authorization also have different purposes. Follow the specific wallet protocol for sensitive material; do not collect a customer’s private signing information simply because the server needs to call an API.

Build the uncertain states into the design

Plan how the interface explains pending work, expired attempts, missing evidence, and denied operations. Retain references that let support investigate without asking for secrets. Test the supported read path first, then agree any signing or funding integration separately. If a later step is not enabled, make that clear rather than hiding it behind a button that appears actionable. The best embedded experience keeps the existing application familiar while accurately showing the wallet’s actual boundaries.

Illustrative example

An existing application first adds wallet-status visibility before a separately approved signing integration.

In plain language

Permission, signing, and completion are different

Think of a business bank payment: preparing the instruction, approving it, and seeing it complete are separate events. A wallet workflow also has distinct responsibilities. Authorization means the required person or policy permits a particular action. Signing means the participating systems produce the cryptographic signature needed for that action. Completion means the relevant system has accepted or settled the result under its rules. A screen displaying a wallet, or a service responding successfully, does not combine these steps into one. In Hybrid-Chain, customer authorization is separate from distributed signing participation. When reviewing a status, ask which of these stages it describes, which asset and network it concerns, and whether the evidence is current. This distinction helps prevent a common mistake: treating an informational record as permission to move money. An operator should be able to explain the stage in ordinary language without asking you to share any secret material.

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

A read integration does not activate a wallet or authorize transfers. Authentication, wallet generation, network, and operation gates still apply.

What to do next

Begin with the current wallet contracts and confirm where customer authorization belongs in your application.

Native MPC Wallets ↗Developer portal ↗