Media
5 items
Description
A powerful, full-control EVM wallet: HD multi-account, any network, any token, your RPC passed through verbatim. United Starship is a powerful EVM wallet that does exactly what you tell it. Published by Callister Inc. It is a full BIP-39 HD wallet - multiple accounts, import by Secret Recovery Phrase or by private key - with complete control over every network, RPC endpoint and token it touches. Point it at a local node, a fork, or a live chain: it connects to the JSON-RPC endpoint you configure and passes your calls through verbatim, cheat and dev methods included. It never substitutes hosted data, and it applies no address, network, or token blocklist. The responsibility that comes with that control is stated on every screen rather than buried. A slim caution bar reads "Verify the RPC URL and chain ID before you connect or sign. No network or phishing checks stand in the way." It sits on every popup, every approval, and every onboarding screen. Each approval names the chain ID and the RPC URL the request will be sent to. This wallet does not claim to vet any of it for you, and it will not pretend to have checks it does not have. If you have ever watched a wallet refuse a custom network, swallow a node cheat call, or quietly answer a balance query from someone else's server, this is the wallet that does not do that. CREATE YOUR WALLET Generate a 12- or 24-word Secret Recovery Phrase, back it up, and confirm it - exactly like the wallets you already know. There is nothing exotic about the key handling here, and that is deliberate: your phrase restores this wallet on any BIP-39 device, and any BIP-39 phrase restores into this one. You can also import an existing HD wallet by Secret Recovery Phrase, or bring in a standalone account by private key. Both live in the same encrypted vault. At any point you can reveal the Secret Recovery Phrase again, or show an individual account's private key, behind your passphrase. Your keys are not held hostage by the software that stores them. MULTIPLE ACCOUNTS Derive as many HD accounts as you want from the one phrase, import standalone keys alongside them, and switch the active account whenever you like. Accounts can be renamed, and imported ones are labelled as imported so you always know which are derived from your phrase and which are not. Each account shows its own balance on the network you have selected, read from the endpoint you configured. ANY NETWORK A catalog of common EVM chains is one click away, each with a locally bundled logo, because the wallet fetches no remote assets. Beyond the catalog you can add any chain ID and any HTTP or HTTPS RPC host. Duplicate chain IDs are allowed. Mainnet is not reserved. There is no allowlist and no blocklist. If your node answers JSON-RPC, this wallet will talk to it. EVERY NETWORK IS YOURS TO CONFIGURE Every network is editable - including the ones the wallet shipped with. Rename it, change the chain ID or the symbol, set an explorer URL, and reset it back to the shipped defaults whenever you want. Each network holds a list of RPC endpoints and you choose which one is live. Endpoints are added and removed rather than edited in place, so an entry you are relying on cannot silently become a different endpoint under you. Switching the live endpoint re-reads your balances immediately, and there is an explicit refresh whenever you want to pull again from whichever endpoint is currently selected. This is the difference between a wallet that offers you networks and a wallet that hands you the network layer. YOUR KEYS, YOUR ENDPOINT Native and ERC-20 balances are read with eth_getBalance and balanceOf from the endpoint you configured - local, forked, or live. There is no hosted balance API and no price API, not even on chain 1. What the wallet shows you is what your node said. The balance card names the endpoint the number came from, and the chain ID it came from, right beneath the figure. When you are running three forks and a local node, that line is the difference between confidence and guesswork. GRAB ANY CONTRACT ADDRESS A bundled catalog of widely used ERC-20 tokens, each with a locally bundled logo and a copyable contract address. The address is copyable from the common list as well as from your watched tokens, so you can take a token's address without adding it first. Any ERC-20 can be added by contract address, with symbol and decimals read from the contract itself. SEND ON ANY CHAIN YOU CAN REACH Send the native coin, any watched ERC-20, and any ERC-721 or ERC-1155 item you hold, straight from the wallet. The recipient is checked for shape and EIP-55 checksum. That is all it is checked for - there is no address book, no name resolution, and no scam list, and the wallet says so on the send screen rather than letting you assume otherwise. Max is derived from the same gas and fee numbers the transaction is actually built with, so it does not leave you a few wei short. Amounts are scaled by the asset's own decimals and never pass through a floating-point number; an amount with more precision than the asset can represent is refused outright rather than quietly rounded. Before signing you get an exact review: the amount, the recipient in full, the network and chain ID, the RPC URL, the gas, the fee ceiling, the total debit, and the call itself. Then pending, then confirmed with the transaction hash, and a balance re-read from chain. Everything is signed by your own keyring and broadcast through your configured RPC. There is no hosted relayer standing between you and the node. RECEIVE, WITH THE CHAIN IT IS REALLY ON A Receive action shows the active account as a scannable QR code, with the address in full and a copy affordance. The code carries an EIP-681 payment URI - address plus chain - so a mobile wallet scanning it picks up the chain as well as the address. One tap switches to a bare address for scanners that understand nothing else, and the screen always states which of the two the visible code is carrying. The code is generated inside the extension. No QR service is contacted, so the address you are being paid at is not handed to a third party. And there is a hazard here that most wallets ignore: a chain ID is a claim, not proof. If your endpoint is a fork reporting chain 1, an EIP-681 code saying "@1" tells a scanning phone it is the public chain - and someone could send real money on the real chain believing they were funding your fork. So where the endpoint is demonstrably not the public chain its chain ID claims, the screen says so plainly and defaults to the address-only code, which asserts no chain at all. Where nothing is misleading - a local chain honestly using its own ID, or your own node genuinely on the public chain - it stays quiet. NFTS, FOUND THE ONLY WAY THAT WORKS ON A FORK No NFT indexer covers your local chain or your private fork. So this wallet does not use one. Holdings are discovered by a chunked eth_getLogs sweep of your own configured RPC for incoming ERC-721 and ERC-1155 transfers, then confirmed with a live ownerOf or balanceOf so only what you still hold is listed. The scan is bounded, shows progress, and can be cancelled. You can also add an NFT by contract address, and send any item with safeTransferFrom. Artwork is rendered only where it is stored on chain as a data: URI. An image hosted off chain is never fetched and never rewritten to a public gateway, because doing so would hand your address and IP to whoever hosts it. Those items show their collection, token ID, metadata name and a copyable URI instead of a broken image, and they say plainly that the art is off chain. APPROVALS, FROM YOUR OWN RPC Every allowance the active account has granted, discovered by scanning eth_getLogs on the chain you configured - a local node, a fork, or a live chain no indexer has caught up with. It finds ERC-20 allowances, ERC-721 and ERC-1155 setApprovalForAll operators, single-item ERC-721 approvals, and Permit2 allowances. Unlimited ones are flagged and sorted first. Every allowance shown is re-read from chain rather than inferred from a log, so what you are looking at is current. You choose the scan range - the whole chain from block zero, or a bounded window - and rescan on demand. REVOKE, AND SEE THE CALL Revoke individually or in a batch, or set an ERC-20 or Permit2 allowance to an exact amount instead of zero. The exact call is shown before you sign it - approve(spender, 0) - one transaction per approval, in order, sent to the same RPC as everything else. There is no batching contract, and the wallet tells you that rather than letting you assume your revocations are atomic. This is a developer inspector, not a security product. It consults no exploit database, no phishing list, and no scam score, and it makes no judgement about whether a spender is safe. It reports what your own RPC returns, and nothing more. ACTIVITY A record of what this wallet sent from the active account on the active network, newest first: status, amount, counterparty, block, and a copyable transaction hash. It is honest about what it is - the wallet's own record of what it signed, not full chain history, which would need an indexer this wallet does not use. A transaction still in flight is flagged so it is never lost track of. APPROVALS FOR DAPPS, WITH THE CALL DECODED Every connection, network change, token add, transaction and message needs an explicit in-extension approval. Each approval screen names the requesting site, the network, the chain ID and the RPC URL the request will be sent to, and what the request actually does: from, to, value, gas and fee for a transaction, with the calldata decoded to a method name and named parameters where that can be done locally from standard ERC-20, ERC-721 and ERC-1155 signatures. Anything it cannot decode with certainty is shown as raw hex and labelled undecoded. It never invents a decode, and it never fetches an ABI or consults a signature-lookup service to produce one. personal_sign messages are shown as readable text when the bytes are valid printable UTF-8, and as hex when they are not. eth_signTypedData_v4 shows the domain, the primary type, and the message fields. Connected sites can be revoked from the popup at any time. IT LOCKS ITSELF, AND THE LOCK IS REAL The wallet locks after a period of inactivity - 13 minutes by default, configurable, including an explicit never - and wipes the decrypted keys from memory when it does. Locking is not a screen over a still-unlocked wallet. Only using the wallet counts as activity. A dapp making requests in the background does not keep it unlocked. IT COEXISTS WITH THE WALLETS YOU ALREADY HAVE United Starship exposes a standard EIP-1193 provider and announces itself for EIP-6963 discovery as "United Starship" (rdns inc.callister.unitedstarship). It does not impersonate another wallet, ever. By default it claims window.ethereum only when no other provider is present, so it sits alongside your existing wallet through EIP-6963 rather than fighting it for the slot. The provider is always reachable as window.ussEthereum, and an opt-in flag lets you claim the legacy window.ethereum slot if that is what you want. POWER AND CONTROL, AND WHY THAT IS DIFFERENT Consumer wallets decide things on your behalf. They warn on or restrict unusual custom networks, they do not exist to pass arbitrary node cheat and dev methods straight through, they layer on phishing, allowance and scam heuristics, and they are not built for adding and discarding networks and tokens at speed. Those are the right defaults for most people. They are also a wall between you and the chain when you know exactly what you are doing. United Starship is a full-featured wallet in its own right - a BIP-39 HD wallet with multiple accounts, import by phrase or private key, a network switcher over a bundled catalog, a bundled token catalog. What sets it apart is not a shorter feature list. It is that it gets out of your way: Verbatim configured-RPC passthrough, cheat and dev methods included. Unknown methods are forwarded, not rejected. Any network and any token - any chain ID including duplicates, any HTTP or HTTPS RPC host, any ERC-20 address. No allowlist, no blocklist. Sign against any chain you select - local, forked, or live - with balances read straight from your RPC, even on chain 1. Approvals inspection and revocation on any chain you can reach, including ones no public indexer has ever seen. And the trade-off is stated plainly and permanently rather than hidden. What the wallet will not do is pretend to have checks it does not have. WHAT IT DELIBERATELY DOES NOT DO No analytics, no telemetry, no tracking. No price, portfolio, token-list, phishing, scam-scoring or simulation service. No approval risk scoring, exploit database, or hosted approval indexer. The approvals inspector reports only what your own RPC returns. No hosted wallet API and no external detection service. The approval screens state this literally: "Check the chain ID and RPC URL above before you approve. United Starship sends this request to that endpoint exactly as written: it does not simulate, block, score, or forward it to any external service." No remote asset fetching. Every network and token logo is bundled locally. No hardware wallet, no cloud sync, and no developer-run recovery service. Your own Secret Recovery Phrase restores the wallet - there is nobody to ask. KEYS AND STORAGE You either create a new BIP-39 HD wallet - a 12- or 24-word Secret Recovery Phrase - or import one, and you can also import standalone accounts by private key. The phrase and any imported private keys are held in one vault encrypted with AES-256-GCM, using a key derived by PBKDF2-SHA-256 with 310,000 iterations from a passphrase you choose (minimum 8 characters). The encrypted vault is stored only in chrome.storage.local on your own device and is never transmitted. The decrypted seed and private keys exist only in the ephemeral memory of an offscreen document, never in the service worker, and are gone when the browser session ends. Public account metadata - account names and addresses, and which account is active - plus your networks, tokens and per-site permissions are stored as ordinary local data in the same chrome.storage.local. Only the vault is encrypted, and none of it is transmitted anywhere. NETWORK EGRESS The only runtime network egress is JSON-RPC POST requests to the RPC URL or URLs you configure. Nothing is sent to any developer-controlled server. That includes the approvals inspector and the NFT scan: both are eth_getLogs plus follow-up eth_call reads against your own endpoint, with no indexer and no third-party API involved. That is the whole list. There is no second sentence to it. Published by Callister Inc. Open source (MIT): https://github.com/Callister-Inc/united-starship