01
Local-first wallet state
Accounts, address labels, preferences, and encrypted key material are stored on the device. The app does not require a hosted WLD Wallet account.
Developer surface
Developer docs for a verifiable desktop wallet.
Build from source, review release integrity, connect World Chain tooling, and contribute changes with a clean audit trail.
Overview
Everything needed to inspect, run, and extend WLD Wallet.
The desktop app is designed around local key custody, explicit signing, reproducible releases, and narrow network access to Ethereum and World Chain endpoints. Treat the public source repository and signed release manifest as the source of truth for implementation details.
02
Chain adapters
Network code is separated by adapter boundaries so Ethereum mainnet, World Chain, testnets, and custom RPC endpoints can be reviewed independently.
03
Explicit signing path
Transaction construction, simulation, confirmation, and signature submission are separate steps. Hardware-wallet signing stays isolated from network submission.
Use the release-linked repository.
Clone source only from the repository linked in the signed release notes or official GitHub profile. Release tags should be immutable, signed, and match the checksum manifest published with each desktop build.
Review boundaries before shipping changes.
Wallet storage, key derivation, signing, RPC calls, update checks, and build scripts are high-review areas. Changes in those paths should include tests, threat-model notes, and reviewer sign-off.
Build from source
Reproduce a local build before trusting a binary.
Use the exact lockfile, runtime version, and build target from the app repository. If the repository ships a reproducible-build script, prefer it over hand-running individual bundler commands.
- 1
Clone the official repository and check out the signed release tag you want to verify.
- 2
Install dependencies from the committed lockfile. Do not upgrade packages during verification.
- 3
Run lint, unit tests, wallet-storage tests, and signing-flow tests before packaging.
- 4
Build the desktop target for your OS, then compare the generated digest with the published manifest.
git clone <official-wld-wallet-repository>
cd <repository>
git checkout <signed-release-tag>
corepack enable
pnpm install --frozen-lockfile
pnpm test
pnpm build
If your digest differs, rebuild in a clean environment before opening an issue. Include OS version, CPU architecture, package-manager version, and the exact release tag.
Open an issue before large work.
Discuss wallet behavior, security-sensitive changes, new network integrations, and release-process changes before implementation. UI copy, docs, tests, and small fixes can go straight to a pull request.
Keep pull requests auditable.
Use one topic per PR, include screenshots for UI changes, document migrations, and add tests for wallet state, transaction formatting, RPC fallback, checksum parsing, and hardware-wallet paths.
Protect user funds by default.
Never log private keys, seed phrases, full hardware-wallet responses, or unsigned transaction payloads containing sensitive metadata. New integrations should fail closed and show clear recovery paths.
License
MIT for public wallet code.
WLD Wallet source is intended to be auditable and reusable under the MIT License. See the full license text and keep copyright notices intact when distributing modified builds.