Mock Wallet

Use the official mock wallet safely

The official Solana Mobile mock wallet is a development tool for testing Mobile Wallet Adapter. Its purpose is to exercise wallet association and approvals in a controlled environment. It is not a production custody solution and should never hold real funds. In a devnet workflow, it can supply a development signing account, but its authentication and request support must be checked against the operations EdgeORE actually uses.

Build a separate test application

Obtain the mock wallet from the official solana-mobile repository and pin the revision. Build it independently from EdgeORE. Keep its package, source revision, APK hash and configuration in the test manifest. Installing a wallet does not require adding its source files to the EdgeORE app. Separating the projects preserves the security boundary and avoids accidentally embedding test keys inside the dApp.

By default, the mock wallet can create a development keypair. If importing a key for a controlled test, follow the repository's documented development-only configuration and keep that private material out of version control, public logs and hosted screenshots. An example address supplied in a chat cannot be used as a private key. Never ask an agent to reconstruct or obtain signing authority from a public key.

Configure device authentication

The upstream instructions require a secure lock screen for authenticated key use. Set a PIN, pattern or supported biometric in the emulator or device before testing. If fingerprint simulation is part of the environment, confirm that it actually unlocks the wallet's signing key. Passing a visible prompt does not necessarily mean a key-use authorization remains valid in that particular hosted runtime.

Authenticate in the wallet as directed by its current README, then return to EdgeORE and request authorization. Record whether the wallet sheet appears, whether approval completes and whether EdgeORE receives an account. If a second fingerprint prompt appears unexpectedly, preserve that sequence as a diagnostic observation. Do not silently modify the wallet to disable security and then describe the result as equivalent to the standard build.

Check the required requests

EdgeORE's design separates signing from submission. Therefore the wallet used for qualification needs to support the relevant sign-only request, not merely a combined sign-and-send example from a quickstart. Inspect the pinned mock wallet implementation or capabilities rather than assuming its feature list covers every method. A test wallet that submits automatically cannot replace the separate-submit gate without changing what is being tested.

If an alternative development build bypasses authentication to diagnose a host limitation, label it explicitly and preserve the diff. Such a result can isolate a failure, but it does not close a production-authentication gate. The dApp should still verify returned message bytes and the wallet signature. A test wallet must not become an excuse to accept arbitrary signed-looking data.

Finish with a bounded result

The mock wallet test should establish a named request and its outcome: authorize succeeded, request refused, sign-only unsupported, authentication failed or connection unavailable. Keep those outcomes separate. After a successful connection, use devnet-only faucet funds and an explicitly reviewed tiny transfer. At the end of the session, dispose of development credentials according to the environment's lifecycle. The public evidence should contain account addresses and transaction signatures, never the material that can sign again.

---

Wiki home · Qualification updates · Sources and credits