Rabby Wallet: Why Your Professional Liquidator Bot Can’t Use Rabby’s Simulation API—The Rate-Limiting and Throughput Constraint

A professional liquidation bot operator faces a seemingly simple problem: they need to simulate thousands of Ethereum and EVM chain transactions per second to identify profitable positions before execution, but public wallet APIs are not built for that workload. Rabby Wallet, the free and open-source self-custody wallet developed by the DeBank team, includes a transaction simulation feature with risk alerts that works well for individual users reviewing pending transactions. But that same interface cannot sustain 1,000 requests per second or even 100 RPS without degradation, rate limiting, or service interruption. The architectural mismatch is instructive: a tool designed for human transaction verification has fundamentally different throughput and latency requirements than a bot designed to compete in liquidation markets where milliseconds determine profit.

This constraint has led sophisticated liquidation operators to maintain custom forks of Rabby Wallet’s codebase, stripping away UI elements and recompiling the simulation logic to run against private RPC endpoints without rate-limiting overhead. That approach is legal, compatible with the open-source license, and reveals something important about how production DeFi infrastructure differs from wallet software intended for end users. Understanding why that fork exists—and what it tells you about the real bottlenecks in high-frequency chain operations—requires examining the difference between a wallet’s simulation layer and a bot’s execution pipeline.

The architecture of transaction simulation in a consumer wallet

Rabby Wallet’s transaction simulation feature analyzes a pending transaction before the user signs it, displaying warnings about token approvals, balance changes, and potential security risks. This is a defensive design: it catches common mistakes such as approving unlimited token transfers, swapping into unrecognized tokens, or sending funds to a smart contract that may not return them. The simulation runs against a public or user-selected RPC endpoint and models state changes without actually broadcasting the transaction to the network.

For an individual user, this flow is straightforward. A user clicks “send,” the wallet constructs a transaction, the simulation engine runs it against current chain state, and results appear on screen within one or two seconds. The user can then review the risks and decide whether to sign. That latency is acceptable because the user is making a deliberate choice, not racing against market conditions or competing liquidators.

The simulation layer itself must balance correctness against speed. It needs to decode contract ABI data, trace execution paths through smart contracts, account for state changes from pending transactions, and estimate gas usage accurately enough to warn about failures. Running these steps for every transaction the wallet processes creates a baseline computational cost. Rabby Wallet handles this by using established libraries and delegating some work to the selected RPC endpoint, but the endpoint itself has limits. A public endpoint such as Infura, Alchemy, or a community-run node cannot sustain unlimited simulation requests without rate limiting every consumer equally.

The result is that a consumer wallet’s simulation throughput is bounded by endpoint availability and fairness constraints. If one user sends 1,000 requests per second, the endpoint will either reject them, queue them, or degrade service to other clients. Rabby Wallet itself does not enforce per-user rate limiting internally, but the RPC layer acts as the ceiling. That is acceptable for wallet use because users do not typically submit thousands of transactions per second. For a liquidation bot, it is a hard blocker.

Why liquidation bots need custom infrastructure

A liquidation bot’s simulation workload is orders of magnitude higher. The bot must constantly monitor dozens of lending protocols, scan thousands of positions, simulate liquidation transactions against different market conditions, and identify profitable opportunities before executing them. A single liquidation event might involve checking collateral ratios across Ethereum, Polygon, Arbitrum, and Optimism—potentially 100 simulation requests just to evaluate one position. If the bot monitors 10,000 positions and checks each once per block, that is 10,000 simulations per block. On Ethereum, with 12-second blocks, that is roughly 833 RPS sustained, before accounting for redundancy, error recovery, or competitive repricing.

The public Rabby Wallet simulation interface is not designed to handle that load. The wallet’s code is open-source and available on GitHub, but its simulation logic assumes synchronous, low-frequency user interactions. To reach production liquidation speeds, operators need to decouple simulation from the wallet UI, run their own RPC infrastructure, and parallelize the work across multiple nodes or machines.

A custom fork accomplishes exactly that. Liquidators extract the core simulation logic from Rabby Wallet’s codebase—the transaction decoding, state tracing, and contract execution modeling—and integrate it into their own infrastructure. They might run it against a dedicated Ethereum node (such as Geth or Erigon) with local state caching, bypass all user-facing validation layers, and parallelize across multiple workers. The result is simulation throughput measured in thousands of RPS, not the tens of RPS that a public wallet user should expect.

This is not a security vulnerability in Rabby Wallet itself; it is a recognition that rabby wallet was built for transaction verification, not bot infrastructure. The open-source license explicitly permits this kind of derivative use. However, it does reveal how the wallet’s architecture constrains its applicability in professional trading environments.

Rate limiting, RPC infrastructure, and the real bottleneck

The rate-limiting bottleneck is not primarily Rabby Wallet’s code. It is the RPC endpoint. When Rabby Wallet simulates a transaction, it sends a call to an Ethereum RPC provider—typically eth_call or eth_simulateExecution—and waits for the response. Public RPC endpoints rate-limit by IP address, API key, or account. A free tier might allow 100 requests per second; a paid tier might allow 1,000 or 10,000. But that allocation is shared across all clients using the same key or endpoint.

Liquidators solve this by running private RPC infrastructure. A private Geth or Erigon node with an attached local database can serve unlimited simulation requests from the same machine or local network. The bottleneck shifts from endpoint availability to compute resources—CPU, disk I/O, and network bandwidth. A well-tuned node can easily sustain 10,000+ RPS of read-only simulation calls. That is the throughput that a liquidation bot requires.

Rabby Wallet users do not need private RPC infrastructure because they make tens of transactions per day, not thousands per second. But the wallet’s architecture does not prohibit using a private endpoint either. An advanced user can configure Rabby Wallet to point to their own Geth node instead of a public endpoint, which improves both performance and privacy. However, even with a private endpoint, Rabby Wallet’s wallet UI and user-facing code add latency overhead. A bot needs the simulation layer without the wallet chrome.

The fork strategy also addresses provider-specific quirks. Different RPC providers implement simulation methods slightly differently. Some support eth_call with state overrides; others use custom methods like eth_simulateExecution. A bot that needs consistent behavior across multiple chains must either normalize these differences in its code or run against a standardized local node. A custom Rabby fork can include provider abstraction and fallback logic that would be overkill for an individual wallet user.

Transaction simulation as a service versus wallet feature

This distinction—simulation as a service versus a wallet feature—is becoming more important as DeFi applications mature. Some protocols, such as Safe and Uniswap, operate their own simulation infrastructure. Others, like Aave and MakerDAO, publish simulation libraries. Rabby Wallet’s simulation feature is part of the wallet, tightly coupled to the signing flow and UI. Separating it into a reusable library or API would make the wallet’s code more modular and useful to bot operators without requiring a fork.

That separation has not happened, likely because Rabby Wallet’s primary use case is human end-users, and decoupling simulation adds development burden without immediate user benefit. The Ethereum protocol does not define a standard simulation interface; each implementation chooses its own approach. The EIP standards include specifications for things like permit signatures and token transfers, but not for transaction simulation itself.

As a result, bot operators have three options: use public RPC provider APIs (limited throughput), run a private node and use low-level RPC calls (more work, more infrastructure), or fork an existing wallet that already includes simulation logic (Rabby’s approach). The fork is attractive because it reuses tested code, but it creates a divergence from the official wallet. Updates to Rabby Wallet’s security audits, risk detection, or EVM compatibility may not propagate to the fork, which is a liability for operators handling large positions.

Security and audit implications of forking

Rabby Wallet has undergone security audits and is maintained by the DeBank team. The open-source codebase means independent auditors and the community can review the code, and vulnerabilities can be disclosed and patched. When a liquidator forks the code, they inherit both the benefits and the risks. They get tested simulation logic, but they also inherit responsibility for staying current with security fixes.

A vulnerability in the original Rabby Wallet—such as an incorrect gas estimation or a mishandled state trace—could propagate silently into a fork if the operator does not track upstream changes. The bot might then submit liquidation transactions with incorrect gas limits or approve token transfers that exceed intended amounts. In high-stakes liquidation markets, those errors can be expensive.

Professional liquidators mitigate this by maintaining their own security practices: code review of upstream changes, unit tests specific to their use case, simulation against test networks, and staged rollout to production. A smaller operator running a fork without those controls is taking on compounding risk. The open-source license gives them the legal right to fork; it does not guarantee that they can maintain the code safely.

OpenZeppelin and other security firms publish audit standards for smart contracts, but wallet code and bot infrastructure are less standardized. A liquidation bot is not a smart contract; it runs off-chain and does not have the same transparency or immutability. Auditing bot behavior is harder than auditing contract code because the bot’s actions depend on market state, network timing, and the operator’s configuration. That makes staying synchronized with an upstream Rabby fork even more critical.

Hardware wallet integration and multi-chain simulation

Rabby Wallet supports hardware wallets including Ledger, Trezor, Keystone, OneKey, GridPlus, and BitBox02. This allows users to sign transactions with private keys held on a hardware device while the wallet software provides UI and simulation. For a professional liquidator, hardware wallet support is less relevant because bots typically use software keys or hardware modules designed for automation, not consumer devices.

However, the multi-chain simulation capability is relevant. Rabby Wallet supports Ethereum and 90+ EVM chains—Polygon, Arbitrum, Optimism, Base, Avalanche, and others. A liquidator operating across multiple chains needs simulation logic that works consistently regardless of chain. Forking Rabby Wallet gives them that consistency. They do not have to write separate simulation engines for Polygon versus Ethereum; the core logic is chain-agnostic at the simulation layer.

That said, some chains have different execution semantics or RPC implementations. Polygon has different block times and gas pricing. Arbitrum uses a different state model for rollup execution. A bot needs to account for those differences, and a direct fork of Rabby Wallet’s simulation code may not capture all of them without additional tuning. The open-source nature of Rabby Wallet means liquidators can contribute improvements back upstream, but many do not, creating a fragmentation problem.

Why the simulation API remains consumer-focused

Rabby Wallet’s simulation feature is intentionally designed for individual users, not infrastructure. The risk alerts, the decoded approval warnings, and the gas estimation are all components that serve human decision-making. A bot does not need those warnings; it needs raw simulation data and throughput. Splitting those concerns would require Rabby Wallet to expose a separate simulation API—which would entail versioning, documentation, support commitments, and rate-limiting policy. For a free wallet, those are not trivial costs.

The economic model also matters. Rabby Wallet charges 0.25% on swaps and bridges, with free stablecoin pair swaps and reduced rates for large trades. That revenue model depends on users interacting with the wallet UI and making transactions through the integrated swap and bridge features. If simulation were offered as a free API to bots, it would consume infrastructure without generating swap volume. The incentive structure pushes toward keeping simulation as a wallet feature, not a service.

This is a structural tension in open-source infrastructure. Users and developers benefit from code being open and forkable, but maintainers often cannot afford to support all downstream use cases. The right solution for Rabby Wallet might be to publish a clear simulation library that bots can import, separate from the wallet, with documented limitations and throughput expectations. Until that happens, the fork remains the practical solution.

The future of modular simulation in DeFi wallets

As DeFi becomes more professional, we should expect wallets to modularize their simulation layers. A standard simulation library, versioned and maintained separately from the wallet UI, would benefit both end users and infrastructure operators. It would reduce code duplication, make security audits more focused, and clarify the contract between consumers and maintainers.

The GitHub ecosystem supports this: separating Rabby Wallet’s simulation logic into a standalone npm package would be straightforward. Liquidators could import it directly, receive updates automatically, and contribute back to a focused module. The wallet could continue to evolve its UI and features independently. This is how mature open-source projects typically operate—core functionality separated into libraries, higher-level tools built on top.

Until that happens, the fork strategy will persist. Professional operators will continue to maintain custom Rabby Wallet derivatives because the simulation layer is valuable and the open-source license permits it. That outcome is not ideal for security or community coordination, but it reflects the reality of how professional infrastructure develops: when a tool solves 80% of the problem but is not quite designed for the use case, capable operators will fork and adapt it rather than build from scratch. Rabby Wallet’s architecture enables that; it just means that sophisticated liquidators operate in a different layer than the wallet’s intended users.