Web page (untrusted)
A page can make requests — connect, present a transaction for confirmation. That is all. It never receives a key and cannot trigger anything without your confirmation. In beginner mode it cannot reach the wallet at all.
Security
This page describes how the wallet is built, what it protects against — and what it explicitly does not. The second part matters more.
Project status
This wallet runs on the test network (no real money) and is not published in the browser stores yet. It has not been audited.
The rules we do not negotiate
- 01
Keys leave the background process only when you explicitly ask
A decrypted recovery key is never handed to a web page or sent over the network, and signing happens exclusively inside the protected background process. Exactly one method returns recovery material: showing you your recovery phrase so you can write it down. Only you can trigger it, it asks for your password every single time, and it re-decrypts the stored blob from scratch to do so. Without that one exception you could not make a backup.
- 02
Nothing unencrypted is ever stored
Persistent storage holds one encrypted blob plus non-sensitive settings. Encryption is AES-256-GCM; the key is derived from your password with Argon2id, which makes GPU-driven brute force substantially more expensive than older alternatives.
- 03
No remotely loaded code
No CDN, no eval, no dynamic imports from external URLs. The code we ship is the code that runs. It is also a hard prerequisite for approval in the Chrome Web Store and on Mozilla Add-ons.
- 04
No telemetry call. None at all
No analytics, no crash reporting, no usage measurement. Network traffic goes only to the Stellar endpoints configured in settings.
- 05
Every signature is confirmed — in plain language
No action that uses your keys happens without explicit confirmation. And you only ever confirm something that was first stated in words you can understand, not a string of hexadecimal. The dialog also names the network, and warns you outright when a dApp declares a different network from the one the wallet is set to.
- 06
Key material is erased, as far as JavaScript allows
The seed and the encryption key are held in byte buffers and actively overwritten after use. It is not absolute: the recovery phrase and your password travel through the runtime as JavaScript strings, and those cannot be reliably erased in JavaScript — they are immutable, and garbage collection may copy them at will. We would rather say so than claim an absolute the code does not deliver.
- 07
Beginners have no web attack surface
The script that lets web pages talk to the wallet is registered only when developer mode is on. While you are in beginner mode, no web page can reach the wallet — malicious ones included.
Three contexts, one boundary
The wallet is deliberately split into three separate contexts. Keys exist only in the middle one. Everything else has to ask.
Background process (the only place with keys)
Decrypted keys live here — in memory only, and only while unlocked. An auto-lock timer (15 minutes by default, configurable) ends the session on its own. This context signs transactions and never releases a key. Requests to the Stellar network are also brokered here.
Popup interface (holds no key of its own)
It displays balances, asks for your password and renders confirmation dialogs. Compromise the interface and you still have no signing key — it simply does not have one. The single exception is the moment you deliberately ask to see your recovery phrase: then it is on screen, for as long as that screen is open.
Plain language before the signature
Most real-world damage does not come from broken cryptography. It comes from confirmations nobody understood. So the wallet translates every transaction into plain language and actively flags risky patterns. It detects at least:
- Changes to your account’s signers or thresholds
- Removing an asset approval (limit set to zero)
- Account merge — your account is emptied and closed
- Path payments with more than 2 % slippage against the expected rate
- An asset whose issuer we do not recognise
- A recipient account that does not exist yet — a reserved account balance becomes due
- A gap in the transaction sequence number
- A mismatch between the network a dApp declares and the network the wallet is actually on
And when an operation shows up that we cannot translate, it is not waved through in silence. The dialog says: "We cannot translate this operation into plain language." When in doubt we would rather warn too often. Every confirmation also names the network being signed against, and marks the main network as involving real funds.
Threat model
What phase 1 covers
- A malicious web page trying to get at your keys
- A phishing dApp trying to trick you into a harmful signature
- Theft of the stored wallet file while the wallet is locked
- Confirming something by accident because the interface was unclear about it
What it does not cover
- A compromised operating system — whoever controls your machine controls your browser
- Another malicious browser extension with debugger access
- Physical access to your device while the wallet is unlocked
- Loss of your recovery phrase — no software can fix that
What we do not have yet
This list is prominent on purpose. It gets shorter as we make progress — not when we change the subject.
No external security audit
No independent third-party review has taken place. Until one exists and is published, treat this software as unaudited. We will change this section the moment there is something to report.
Test-network phase
The wallet starts on the test network. The main network can be selected, but only deliberately: a typed confirmation, its own browser permission, and a permanent red marker in the header. It is neither audited nor released for that — anyone trying it there should risk only an amount they can afford to lose, and never a recovery phrase that also guards other balances.
No bug bounty programme
We cannot pay for security reports right now. Report findings anyway — and we will credit you by name if you want us to.
No hardware wallet support
Connecting hardware devices is not a phase 1 goal. For larger amounts a hardware wallet remains the safer route. We would rather say that plainly than leave it out.
Multisig is display-only
Accounts with multiple signers have their signers and thresholds displayed in developer mode — and nothing more. There is no multisig signing flow: no collecting of signatures, no importing a partially signed transaction, no coordination with other signers.
No decoding of Soroban arguments
A smart contract call can be signed in developer mode, and the dialog names the contract and warns about the invocation. But we do not yet translate the function arguments into plain language — so for exactly that operation type you confirm with less information than for an ordinary payment. It is the largest known gap in our plain-language promise, and it is at the top of the list.
No runtime test in a real browser yet
Cryptography, key derivation and transaction description are covered by unit tests, and the derivation is additionally checked against the official SEP-0005 test vectors. What is missing is an automated run that installs the extension in Chrome or Firefox and completes a payment. Until then: the build works and the unit tests pass — we claim nothing beyond that.
Not through store review
The extension has not passed Chrome Web Store or Mozilla Add-ons review. For now, install it from source and only if you know what you are doing.
Found a vulnerability?
Please report it to us first rather than publicly, so we can fix it before it is exploited. We respond as quickly as we can and keep you posted on the fix.
Placeholder Security contact address — to be filled in by Rene