Why token staking breaks in a mobile wallet
Token staking in a mobile wallet breaks not at the blockchain level, but at the junction of three layers: transaction signing, state synchronization with the network, and key storage on the device. Each layer produces its own class of failures, and in production they usually arrive together.
The first and most common one is a stuck transaction. The user signed a staking operation, the app went to the background, the network dropped for a few seconds, and the nonce has already been spent.
The transaction either hangs in the mempool or is rejected on timeout, but the interface shows "in progress." The person taps again — and gets a second operation with the same nonce.
This is fixed not by "improving connectivity," but by an explicit operation lifecycle: a local state journal, an idempotent retry using the saved hash, a separate path for replacing a stuck transaction, and a clear status instead of an endless spinner.
The second class is state desynchronization. Staking rewards accrue in epochs, while the mobile wallet shows a balance from a cache that was refreshed before the epoch closed. The user sees zero rewards, writes to support, even though everything has been credited on-chain.
What works here is a scheme with an explicit source of truth: state is read from the network on a schedule and on an event, the cache is tagged with a timestamp and epoch version, and a discrepancy between the local and network models is resolved in favor of the network with a visible "data is updating" indicator.
The third and most expensive one is key storage. A key placed in ordinary app settings or in a hand-rolled file is read on a rooted or compromised device within minutes. For staking this is a direct loss of funds: unstaking is signed with the same key.
That is why the key lives only in the platform's secure storage, the private part never leaves its boundaries, and signing is performed inside the secure enclave. Biometrics and a passcode are access to an operation, not a replacement for cryptography.
All three failures share one thing: the app does not distinguish between "the operation was accepted by the network" and "the operation was shown to the user." Let's break down how this is closed at the wallet architecture level.
What a correct staking implementation delivers
Correct token staking in a mobile wallet is not a "delegate button" but a set of invariants that keep the balance and the operation status in a consistent state.
We design the logic so that the user at any moment sees the current share, rewards, and the withdrawable remainder — without "stuck" transactions and manual reconciliations on the support side.
What we measure on the output
The share of successful operations reaches above 99%: signing, sending, and confirmation follow a single scenario, and errors like "insufficient funds for the fee" are cut off before sending.
Confirmation time is reduced by reusing the connection and resending only when there is a real absence of a response — instead of a blind retry that breeds duplicates.
The load on support drops severalfold: typical requests like "tokens were debited but there is no stake" and "rewards were not credited" are closed by the interface itself — the operation status, hash, and a clear reason for failure are visible right in the wallet.
Resilience to disconnection
A mobile network drops in the subway, elevator, roaming — the operation must not "get lost" because of this.
We store the intent locally and see it through to the end when connectivity is restored, reconciling the final state with the network rather than relying on the app's memory.
This is the class of failures that most often hits trust: the user once fails to see their tokens — and never comes back.
We practice this approach on professional equipment and in test networks, running scenarios with connectivity loss and re-entry — that is why in production the behavior is predictable, not "however it goes."
Network Connection Options and Their Limitations
Connecting a wallet to the network is not "a single line in a config," but a choice between three architectures with different costs of ownership.
Below is how they differ in reliability, latency, and scope of maintenance, so the decision is made before development starts, not after the first incident.
| Option | When it fits | Limitations |
|---|---|---|
| Own node | High requirements for independence and control over data; readiness to maintain infrastructure | Full maintenance cycle: network updates, synchronization monitoring, redundancy, on-call duty. As load grows — a dedicated team |
| Network provider | Quick start, small team, no desire to maintain infrastructure | Dependence on an external service: request limits, changes to pricing and rules, risk of degradation on their side. Latency is determined by the route to the provider |
| Hybrid scheme | Need for balance: critical operations — on your own, mass operations — through a provider | More complex routing and failover logic. Requires explicit rules for which request goes where |
Reliability and Latency
Reliability is determined not by the "power" of an option, but by the number of failure points. An own node provides predictable latency within your network, but adds risk on the infrastructure side: missed an update — the node fell behind the network.
A provider removes this concern, but introduces external dependence: when it degrades, the wallet loses access to balances and staking operations.
A hybrid covers both risks, but requires well-thought-out failover — otherwise, when one channel fails, requests do not go to the backup.
What This Means for Maintenance
Maintenance is the main cost item in the long run. An own node means constant updates, monitoring, on-call duty, and scheduled maintenance. A provider means a contract, limit control, and readiness to change suppliers.
A hybrid also means supporting routing logic, channel failure tests, and clear rules for when the system switches over on its own and when it requires an engineer's intervention.
We build these scenarios into the architecture from the start, so that load growth does not turn into outages.
Stages of integrating staking into an app
Integrating token staking into a mobile wallet is not about "adding a Stake button" but about rebuilding how keys, the network, and state are handled. Below is the route our team follows: from auditing the current wallet to handing over to support. Each stage ends with an artifact that can be verified, not a verbal "done."
- Wallet audit. We analyze the current architecture: where keys are stored, how access to the device's secure storage is structured, which networks are already connected. The output is a map of bottlenecks: usually the lack of separation between hot and cold operations and hardcoded node addresses.
- Designing signing flows. Staking adds delegation, undelegation, and revoting transactions — each requires its own confirmation logic. We describe what the user sees on screen, what they sign, and how the app behaves when an operation is rejected.
- Node setup. We select a network connection scheme: a proprietary node, a backup provider, or a combination of both. We configure failover when the primary one is unavailable — the user should not see a frozen screen.
- Testing on a testnet. We run the full cycle: delegation, reward accrual, withdrawal, cancellation. We separately test behavior during a connection drop and when a transaction is resubmitted.
- Handover. We deliver to the client's team the configurations, flow diagrams, and maintenance documentation — describing what to change and where when network parameters change.
This route eliminates the main risk: staking stops being a separate module and becomes embedded in the wallet's existing logic. Describe your task — we'll come back with an estimate and a plan based on these stages.
What the client receives as a result of the work
As a result of the work, the client receives not "source files and repository access", but a package that allows the system to be operated, developed, and handed over to another team without losing context. Below is what exactly is captured in the delivered package.
- Node configurations — network connection parameters, validator operating modes, timeouts and limits, moved into separate profiles for each environment. Deployment is repeatable on a clean machine without manual edits.
- Flow diagrams — how the staking operation proceeds end to end: from signing in the application to confirmation in the network, including error branches, retries, and the states in which an operation is considered stuck.
- Key access policies — where keys are stored, who and under what conditions can initiate signing, and what happens if a device is compromised. Access recovery scenarios are described separately.
- Documentation — a description of the architecture, contracts between modules and external services, instructions for local startup and incident triage.
- Update procedures — the order for rolling out new versions, pre-release checks, and the conditions and procedure for rolling back to the previous build.
- Monitoring and alerts — a set of metrics for staking operations, trigger thresholds, and notification routes for the on-call team.
- Responsibility matrix — which work remains on our side, which transfers to the internal team, and at what point.
Each artifact is verified at acceptance: configurations are deployed on a test environment, diagrams are checked against the actual behavior of the system, and procedures are run through a training update.
If something diverges from reality, it is a handover defect, not a "growth area" for support.
Describe the task — we will come back with an estimate and a plan for how much of this package we will cover on your side.
Case: reducing the share of stuck operations threefold
The client came with a wallet where token staking worked, but users regularly remained in uncertainty: the transaction was signed, but there was no confirmation.
The share of incomplete operations reached 9% of the daily volume — when the network dropped at the delegation stage, the client saw an endless progress bar and wrote to support.
Requests on the topic of "stuck stake" accounted for almost a third of the first line, and investigating each case required manually checking the state on the node.
What was changed
We moved staking to a model with explicit states: request, signature, sending, confirmation, final crediting to the stake.
Each transition is written to a local journal on the device, so after a restart the app does not start from scratch but continues from the last confirmed point.
For resending, we introduced an idempotent operation identifier — the network discards the duplicate, and the client gets the same result instead of a second stake.
Recovery was addressed separately: a background task reconciles the journal with the state on the network on a schedule and, in case of a discrepancy, brings the operation to completion without user involvement.
If there is no confirmation longer than a set threshold, the stake is rolled back and the tokens are returned to the balance — with a clear status in the interface.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Share of stuck operations | 9% | 3% |
| Recovery time after a network drop | until manual intervention | up to 2 minutes automatically |
| Support requests about staking | a third of the first line | isolated cases |
The work was carried out by our engineers on Polygon — a network with predictable behavior on resending, which is what made it possible to rely on idempotency.
The remaining 3% are operations interrupted at the signature stage, when the user closed the app before biometric confirmation; we handle these separately, because an automatic rollback here is impossible without risk to the keys.
How is delegation different from direct staking?
The difference comes down to three things: who holds the private keys, who is responsible for running the node, and how the risk profile is distributed.
With direct staking, the user sets up their own node and keeps the keys themselves — the app only helps with configuration, monitoring, and signing operations.
With delegation, the keys remain with the owner, while the coins are transferred to an operator who runs the node on their behalf.
With direct staking, key ownership is complete: no one but the user can dispose of the funds. But all responsibility for the node rests with them: downtime, missed blocks, incorrect configuration, and updates all fall on the owner.
The app must provide clear diagnostics of the node's state, otherwise the user only finds out about a problem when a penalty hits.
With delegation, responsibility for the node shifts to the operator, while the user retains control over the keys and can withdraw funds. The risk profile shifts: instead of technical failures, the operator's reputation, exit terms, and lock-up periods come to the fore.
Here the app solves a different problem — it transparently shows where the coins went and when they can be returned.
For a mobile wallet, these are two different build scenarios. Direct staking requires monitoring, notifications, and recovery scenarios after a failure. Delegation requires a registry of operators, a history of accruals, and a clear exit.
They cannot be mixed on a single screen: the user must see who is responsible for the node at any given moment and where the keys are held.
Common technical concerns before starting
Concerns are usually the same: whether the wallet will have to be rewritten, where the keys are stored, what will happen when the network updates, and whether the application can handle the load. Below is how these questions are resolved in practice.
We already have a wallet deployed — will staking have to be built from scratch?
No. We work with the current codebase: we add the staking module as a separate layer, reusing the existing transaction signing, address handling, and key storage.
If the architecture allows, staking is connected as a separate screen and service, without affecting the logic of transfers and balances — the already deployed wallet keeps working while integration is underway.
How is key security ensured when signing staking operations?
Private keys never leave the secure perimeter of the device: signing is performed in the same place as for regular transactions — on hardware storage or in an isolated area of the system. Only the signed operation goes outside.
We do not log keys and do not transmit them to the server, and critical actions are confirmed by biometrics or PIN.
What happens when the network updates the staking protocol?
Network updates are a routine scenario, not a failure. We build in versioning of operations and handling of format changes on the service side, so that the application does not require an urgent release on the day of the update.
If the rules for accrual or withdrawal change, the logic is updated on the backend, and the client receives correct data without reinstalling.
Will the application handle the load during mass staking?
Yes. Staking operations are asynchronous: the user sees the status, and confirmation arrives as the network processes it. We separate signing, sending, and status tracking, cache reward data, and do not block the interface.
As the number of users grows, the load is distributed on the service side rather than falling on the device.
Is this compatible with the current versions of the system and devices?
We check compatibility on the current branches of mobile systems and on the customer's fleet of devices, including older models. If some features are unavailable on outdated versions, they are disabled selectively, while basic staking remains functional. Testing covers scenarios of updating the application over an already installed one.
Let's discuss the task and come back with an estimate and a plan
To come back with an estimate and a work plan rather than generalities, we need input data about your token staking. We collect it in a single message — that way the first review takes one round of correspondence instead of a week of clarifications.
- Network and assets. Which networks the wallet operates in, which tokens are staked, whether there are your own validators or delegation to third-party operators.
- Staking model. Fixed term or flexible withdrawal, rewards credited to the balance or reinvested, whether there are lock-up periods and how the yield is calculated.
- Keys and signing. Where private keys are stored, whether hardware wallet support is needed, who signs the transaction — the application or an external module.
- Current state. What already exists: a finished application, a prototype, only interface mockups, or an idea. Whether there is access to the repository and the test network.
- Constraints. Target platforms, load requirements, regulatory frameworks for handling user assets, launch deadlines.
- Team and roles. Who on your side makes product decisions, who is responsible for security, and who will test the scenarios on real devices.
Based on this input, we come back with an estimate and a work plan: a breakdown into stages, team composition, a list of risks, and the points where your decisions are needed.
Separately, we discuss what we do at the first step — usually this is a review of the current code and the key storage scheme, because the rest of the architecture depends on them.
Describe the task in whatever form is convenient — text, a link to the repository, or mockups. Then we will agree on the format of the conversation and come back with an estimate and a plan.