How Aetsoft took over the live Scramble crypto wallet
and rebuilt its backend as shared infrastructure for several crypto apps
Aetsoft inherited the code of Scramble, a browser-extension crypto wallet, with no specifications and no working build. It restored releases and repaired the extension, then replaced its data services with a backend that also serves the client's other apps.
Scramble began as a fork of the open-source Enkrypt wallet from MyEtherWallet and was already live when Aetsoft joined in Q3 2024. Aetsoft has developed the wallet and kept it running in production for more than two years, and the engagement continues.
001
ClientScramble is a non-custodial wallet for sending and swapping tokens across many blockchains, listed in the Chrome Web Store and Microsoft Edge Add-ons. The client also runs other crypto apps.
002
ChallengeUsers could not send tokens on Ethereum-compatible networks, and swaps showed the wrong network fee. The wallet had to stay in the stores while it was repaired. Every logic change in the extension waited for store review, and its data came from free public nodes and Enkrypt's endpoints, none of them under the client's control.
003
SolutionAetsoft restored the extension's build and set up the infrastructure and CI/CD pipelines for continuous delivery. It repaired sends and network fees, then moved token lists, prices, balances and swaps to the new backend. Data changes now deploy without waiting for store review, and an RPC forwarder routes the wallet's requests to healthy nodes.
004
Aetsoft's roleCode review and takeover planning, infrastructure and CI/CD, extension engineering, backend architecture, backend migration, continued product development, and production support and maintenance.
Engagement lead
Artem Kirylin
Commercial Director, Aetsoft Inc
Led the client relationship.
The problem
Scramble was live in two browser stores but could not ship a fix
Scramble was already in the Chrome and Edge stores when we took it over. The product had no specifications, and no handover came with the code. The code would not build into a new version, so we could not ship fixes to the extension through the stores.
For users, the wallet was failing at its basic jobs. Sending tokens on Ethereum-compatible networks failed, and swaps were quoted with the wrong network fee.
The diagnosis
The extension could be repaired, but the client did not control its data sources
With nothing written down, we learned the application from its repositories. We checked which code still ran and which networks still worked, and we traced the wallet's main data sources. This is what we found:
- Most of the browser extension still worked and could be repaired.
- Repairing the hybrid mobile apps would have cost more effort than they were worth.
- The wallet depended on Enkrypt's public endpoints and on public nodes, and we flagged both as weak points. Nodes are servers that hold a copy of a blockchain, and a wallet uses them to read balances and send transactions. Public nodes are free and shared, so they limit how many requests they accept and can be out of date with the chain.
- Any change to logic inside the extension needed a new release through store review.
The diagnosis
The extension could be repaired, but the client did not control its data sources
With nothing written down, we learned the application from its repositories. We checked which code still ran and which networks still worked, and we traced the wallet's main data sources. This is what we found:
- Most of the browser extension still worked and could be repaired.
- Repairing the hybrid mobile apps would have cost more effort than they were worth.
- The wallet depended on Enkrypt's public endpoints and on public nodes, and we flagged both as weak points. Nodes are servers that hold a copy of a blockchain, and a wallet uses them to read balances and send transactions. Public nodes are free and shared, so they limit how many requests they accept and can be out of date with the chain.
- Any change to logic inside the extension needed a new release through store review.
The brief was to get Scramble working again. Before designing a new backend, we looked at the client's whole product line. Several of its apps needed the same token, price and swap data. We proposed a shared backend to serve them, with separate fee settings for each app.
The wallet's existing data services kept it working until the new backend replaced them. The rebuild also gave the client control over the wallet's data. The client's other apps now connect to the new backend, and a new app can reuse the services instead of building its own.
Aetsoft built the shared backend. The client's other apps connect to it, and each has its own fee settings.
On the new backend, an administrator can remove a token from every user's list or switch off a swap provider without releasing a new extension version.
The approach
We stabilised Scramble first, then moved it onto the shared backend
Neither a full rewrite nor patching the extension alone suited Scramble. A rewrite would have kept users waiting for fixes while we rebuilt code that still worked. Patching alone would have left the wallet on free public nodes and Enkrypt's endpoints, and changes to data-handling logic inside the extension would still have needed store review.
We organised the work into two parts: Stabilisation, which kept the live wallet working, and Shared-backend development and migration, which moved Scramble onto the new backend. We also dropped the hybrid mobile apps and put the effort into the browser extension.
Keeping the extension meant giving up Enkrypt's updates. Enkrypt develops in its own direction, with different services and networks, so its updates conflict with Scramble's code and cannot be merged directly. Scramble now evolves as its own fork.
Planning what to keep and what to rebuild before writing new code is part of our blockchain consulting
Blockchain consulting
The solution
Six new services now supply wallet data, and a forwarder manages node access
Scramble still uses outside services: public and paid nodes, swap providers and price sources. It now reaches nodes through the forwarder and swap providers through the swap service, and the new backend supplies the data that used to come from Enkrypt's endpoints.
Network fees are calculated for each fee model
We rewrote fee estimation using the ethers.js library, with economy, default and high settings. Networks that use the EIP-1559 fee model get a separate calculation.
Transactions are built for either model and sent by a reworked broadcaster, the part that delivers a signed transaction to the network.
A forwarder sends each request to a healthy node
An RPC forwarder passes the wallet's requests to blockchain nodes. Ours picks a healthy node for each request, using an administrator's priority order and each node's response time. Once node selection ran through it, users could swap on one chain and between chains again.
We chose Fastify for its light footprint and ready-made proxy plugins, which handle the forwarding while our code chooses the nodes. For Ethereum-compatible nodes, the forwarder asks for the latest block number at a set interval and switches off any node that fails or answers slowly.
An administrator sets the ranking for each network. When free public nodes rank first and paid providers such as Alchemy and Tatum follow, the forwarder turns to paid capacity only when the free nodes fall short. Within that ranking, the forwarder sends each request to the node that answers fastest. Node providers with an API key can be added per network, so the wallet is not tied to a single provider.
The forwarder also caches reads and rate-limits requests. If no healthy node is left, the wallet shows that the network is unavailable. The forwarder works with Ethereum-compatible, Bitcoin and Tron nodes.
Six services supply wallet data and swaps
- Token service: the wallet's token list. It merges several sources and removes duplicates.
- Price service: current prices in US dollars, tracked in the background and cached.
- Liquidity service: excludes tokens that fail the configured liquidity and validation rules, unless an administrator sets a flag to include them.
- Swap service: one interface for quotes from several swap providers, on one chain and between chains. It checks each quote and tracks the status of every swap. We used the same pattern in our DEX aggregator development project for another client.
- Wallet service: a user's balances, collected in one request to speed up loading.
- Admin service: where administrators edit tokens, networks and swap providers.
The new wallet backend is a modular monolith. It runs as one system, but its code is split into separate modules, one for each service. Each service can function separately and uses fallback mechanisms when errors occur.
If the backend reports a swap error, the extension does not carry out the swap and tells the user it cannot proceed right now. When a provider holds a swap for verification, support can find the record by its ID.
The extension predates Aetsoft and was kept. Aetsoft built the forwarder and the six services; the client's other apps use the same backend, and the nodes and providers remain third parties.
New networks and features shipped alongside the rebuild
We added Tron, Base, Solana and Dogecoin, and reworked balance handling for Bitcoin and Litecoin. We restored hardware-wallet connections and connections to decentralised apps (dApps).
We kept the extension within store rules as they changed, including an upgrade to Node 20 when the stores required it. New swap providers cover swaps on one chain and between chains. With the 1inch integration, starting a swap between chains takes two clicks.
How a send works after the rebuild
Take a user who opens Scramble to send tokens on an EIP-1559 network.
Their balances arrive from the wallet service in one request. Tokens that fail the validation rules, such as a fake USDT sent to their address as bait, are left out of the list. Prices come from the backend's cache.
The user picks a fee setting and signs the transaction on their own device. The broadcaster sends it through the forwarder, which picks a healthy node by priority and response time, and the transaction appears in their history. The backend never sees the user's key.
A send as a user experiences it in production. The diagram shows the order of steps, not an exact call trace.
How the engagement run
The wallet stabilised within months, and the rebuild followed in stages
The two parts ran through six overlapping stages. Work moved in cycles of one to three months, each with releases, testing and infrastructure work. New features and regular releases continued during the rebuild.
Part 1: Stabilisation
1. Take over and review the code, without specifications.
2. Decide what to keep, cut and rebuild.
3. Stabilise and release. We set up the infrastructure and CI/CD pipelines and released a working version to the stores. Basic transactions returned on BSC, Ethereum, Polygon, Arbitrum and Optimism. Fee estimation and the node forwarder followed.
Part 2: Shared-backend development and migration
4. Continue product development alongside the rebuild. New networks, swap providers and features shipped from this stage onwards.
5. Rebuild the backend as six services.
6. Migrate from the previous backend to the new one.
We moved the wallet to the new backend function by function instead of in one cutover. While functions moved, the wallet drew on the old and new backends together, so each function could switch over separately.
Before the first move, we prepared the extension to take its token list from the new backend. Token lists and prices moved first, then liquidity checks and balances.
Swaps came last. Each move shipped as a normal release, with testing.
Scramble ships again,
and the planned
backend migration is
complete
Releases
-
Before
The code could not be built
-
After
Regular releases since the first restored version
02/05
Sends and swaps
-
Before
Sends failed; swap fees were wrong
-
After
Sends work; swaps run on one chain and between chains
03/05
Node access
-
Before
Public nodes, called from the extension
-
After
A forwarder that picks nodes by priority and health
04/05
Wallet data
-
Before
Enkrypt's public endpoints
-
After
Six new backend services; the client's other apps use the same backend
05/05
Fixes
-
Before
Logic changes waited for store review
-
After
Backend changes deploy without an extension release
The Scramble product, including its browser extension, existed before Aetsoft joined
We delivered:
- Infrastructure and CI/CD pipelines.
- Fee estimation and the reworked broadcaster.
- An RPC forwarder and six backend services. The client's other apps also connect to the new backend.
- A completed migration from the previous backend to the new one.
- Tron, Base, Solana and Dogecoin, plus Bitcoin and Litecoin balance handling.
- New swap providers, and restored hardware-wallet and dApp connections.
Scramble is live in the Chrome Web Store and Microsoft Edge Add-ons, and Aetsoft continues to develop, support and maintain it.
Frequently asked questions about crypto wallet takeover
-
How do you take over a crypto wallet built by another team?
We split the work into two parts. First we stabilise the product: we review the code and ship a release that fixes the most urgent faults. Then we rebuild the components that limit the product, one function at a time, so releases continue. StreamWolf product engineering is another case where we took over a partly built product.
-
What do you need from us to start?
Access to the code repositories, the store and developer accounts, and the product’s servers. Specifications help, but they are not required. Scramble had none.
-
Do we need to rewrite an inherited crypto wallet?
That depends on which components still serve the product and which limit it. For Scramble, we kept and repaired the extension, so users kept the same wallet. We rebuilt the data services to give the client control of its data and to serve its other apps. Our overview of legacy modernisation strategies compares the wider options.
-
How long does a crypto wallet takeover take?
Scramble had basic transactions back on its main networks within the first months, and the wallet kept releasing while the backend was rebuilt. For another wallet, the timeline depends on the state of its code.
Tell us what you inherited and what it needs to do next, and we will tell you what to fix first and what to rebuild.
