Transaction state
ImplementationIntent, signed, broadcast, included, final
ValidationReplay, nonce conflict, pending replacement
Connect asset views and transfers to your service
Develop addresses, balances, history and transfers around key custody and approval rules
A transfer request is taking time to respond.
- Input
- Request ID · recipient address · network
- Review
- Signing, approval and duplicate requests
NEXT ACTION
Check the existing request before any resubmission
IMPLEMENTATION SCOPE
Explicit signing and transaction states
Define key management and signing authority before chain, node and wallet integrations. Distinguish submitted, pending, confirmed and failed transactions.
- What we build
- Wallet UI · key/signing integration · chain APIs · transaction tracking
- What we validate
- Wrong network, duplicate submission, nonce conflicts, node errors and confirmation changes
When this service helps
When users need balances and transfer status inside your service
- 1
Review a balance and request a transfer
- 2
Check limits, approval and signing
- 3
Track transfer status and history
What the project delivers
- Wallet interface and API
- Key and signing policy implementation
- Status synchronization and recovery checks
Specific features, integrations and operating support are agreed in the project proposal
Start by reviewing your integration needs
Tell us about the chain, custody, approval policies, external modules and operating responsibilities. We will define the needed functionality and acceptance scope.
Discuss this serviceTechnical design and acceptance criteria
Details for technical reviewers. Architecture and acceptance criteria are agreed for the actual environment and project scope.
- Custody boundaries
- Nonce coordination
- EIP-1559 / RPC
- Reorg reconciliation
Processing flow and exceptions
Track intent, signing, broadcasting, inclusion, and finality as distinct states. Pending-transaction replacement and chain reorganizations follow explicit paths rather than being treated as successful completion.
Architecture summary
- Transaction state — Intent, signed, broadcast, included, final
- Chain reconciliation — Block hash, checkpoints, reversion
- Key boundary — Custody, approval, backup, recovery ownership
02Acceptance criteria
Implementation and acceptance criteria
Concrete design decisions and acceptance scenarios to agree for the project.
Chain reconciliation
ImplementationBlock hash, checkpoints, reversion
ValidationReorgs, missed index events, RPC-provider failure
Key boundary
ImplementationCustody, approval, backup, recovery ownership
ValidationExpired approval, recovery, test/production separation
Technology choices and acceptance criteria depend on discovery, integrations, and agreed scope. We define reproducible acceptance scenarios and handover evidence for the operating environment.
03Implementation details
Engineering decisions
in detail
From visible features to failure conditions,
we work through the decisions before launch.
Custody determines key lifetime and recovery responsibility
Choose user custody, operator custody, or an external custodian before designing key management. Specify generation, derivation, encrypted storage, backup, recovery, and rotation, keeping seeds and private keys out of ordinary databases and diagnostics. Compare MPC, multisignature, and hardware signing against the actual approval and recovery model; they are not interchangeable labels.
Validate intent and coordinate nonces before signing
Validate chain ID, recipient, asset, amount, and contract-call data. On EVM chains, coordinate per-account nonces and pending transactions and assess EIP-1559 fee caps, priority fees, and replacement rules. Treat UTXO selection and change as a separate model rather than forcing every chain through the same transaction logic.
Index chain state against block references and reorg history
Distinguish successful RPC broadcast, block inclusion, and finality using a policy appropriate to the chain, asset, and risk. Indexers record processed block numbers and hashes, revert affected events during a reorg, and replay the canonical history. Reconcile internal transfers with chain balances to identify gaps, duplicates, and delays.
Test recovery beyond a successful transfer
Exercise fee spikes, nonce conflicts, node timeouts, retries, and indexer restarts on test networks and controlled environments. Validate expired signing approvals and cancellation or replacement rules. Separate production and test key access, and document independent audit, custody-contract, and jurisdictional responsibilities alongside the software scope.
04Handover
Detailed deliverables
- Custody model, key and signing boundaries, and transaction-state design
- Wallet functions for agreed chains with node and indexer integrations
- Testnet acceptance and recovery, reconciliation, and operating guidance
05Before implementation
Questions before implementation
- Target chains and assets, and user versus operator custody
- Recovery, approval, transfer limits, and external wallet needs
- Target jurisdictions and the stage of operational, security, and legal review
How your project moves forward
Discover
Understand your goals, workflows, and operating environment.
Define
Define features, priorities, and integration requirements.
Build
Build the agreed scope and review progress together.
Launch & Operate
Prepare testing, deployment, and operational handover.
Let’s discuss your project
Tell us what you want to build or improve
Our team will review your request and reply by email