Solana Wallet Manager: wallets, ledger and safe transactions

The problem: manage wallets without financial guesswork

A dashboard with a balance and a transfer button is not enough. A process can stop after sending transaction bytes but before receiving the RPC response. Retrying may create a double spend; releasing the reservation immediately may make the internal balance disagree with the chain.

The system therefore separates the user's economic intent, the technical submission attempt, the observed blockchain movement and the accounting entry. Each has its own lifecycle and history.

What the operator gets

The single outgoing transaction path

Production code has no second “shortcut” for SOL or SPL submission. Every economic intent uses the same pipeline, while architecture tests guard against new direct signing or sendTransaction call sites.

1. Intent and idempotency

   An immutable FinancialOperation and matching outbox event are committed together. Reusing the same key with different economic data is a conflict.

   intent · fingerprint · outbox

2. Reservation

   Funds are reserved atomically before signing. Available balance equals confirmed minus active reservations; all raw amounts remain integer strings.

   ledger · exact amount · lock

3. Preparation and submission

   A TransactionAttempt receives a blockhash, is signed in memory and crosses the network boundary once. Signed bytes and private keys are not persisted.

   prepare · sign · submit once

4. Reconciliation

   A background process verifies the signature and parses source, destination, asset, mint and raw amount. Only matching confirmed evidence closes the reservation.

   reconciliation · chain evidence

5. Settlement or review

   Confirmation settles exactly once. Conflicting provider evidence, mismatches or an unknown result keep the reservation intact and raise an incident.

   settle once · manual review

Handling a timeout after submission

Ledger, chain history and audit are different records

The ledger explains the internal financial balance. A blockchain movement records what was observed on Solana. The audit log records an actor's action. Reconciliation connects an expected operation to chain evidence.

This separation makes queue redelivery, repeated signature reads and observation from both managed sides safe without creating a second credit or settlement.

Access and key custody

• Passwordless administrative access. A known email identity is followed by a short-lived email OTP and authenticator TOTP.
• Encrypted secrets. Private material uses Laravel encryption at rest and is decrypted only in backend memory for signing.
• Private infrastructure. MySQL and Redis expose no host ports and remain on the internal Docker network.
• No financial-state editor. Operators may add append-only notes and trigger policy-bound analysis, but cannot force-confirm, rewrite an amount or delete ledger history.

Observability without automated “money repair”

The system monitors RPC, queues, outbox, reconciliation, recovery and scheduler heartbeats. Metrics allow only bounded low-cardinality labels and exclude wallet addresses, signatures, operation UUIDs, RPC URLs and arbitrary provider text.

Acknowledging or resolving an alert never changes financial state. Monitoring reports operational evidence; ledger and reconciliation rules retain authority over settlement and release.

Explicit limits of the current release

The deployment is locked to Solana Devnet. Three independent feature gates disable new financial operations, low-level submission and Mainnet writes. The MMCP mint is empty; token creation and every Mainnet write are outside this release.

Historical reconciliation is explicitly marked incomplete because the current scanner is limited to the latest 25 signatures per address or token account. The UI exposes this limit instead of presenting a partial scan as complete history.