DEV Community: Miles

python异步请求：一开始写的代码是直接加了async，结果两个函数的请求仍是同步的，单个请求耗时0.3s，两个耗时0.7s。后经调研，发现，需要使用aiohttp请求，才可以实现真正的异步。优化后，总耗时0.4-0.5s左右。

Miles — Tue, 29 Apr 2025 13:33:50 +0000

Types of Quantitative Trading on Solana

Miles — Wed, 23 Apr 2025 15:39:52 +0000

Quantitative trading on Solana generally falls into two categories: Atomic Arbitrage and Looping Arbitrage (Leverage Arbitrage).

Atomic Arbitrage

Leverages Solana’s parallel processing and low-latency features to perform both buy and sell operations within a single transaction (typically a transaction bundle).
Ensures atomicity, meaning the transaction either fully succeeds or fully fails—no partial execution—thus avoiding risks from price fluctuations in between.
Commonly used for arbitrage between DEXs such as Orca, Raydium, and Jupiter.

Looping Arbitrage / Leverage Arbitrage

Example:

Stake SOL on a protocol for a 12% annual return.
Use the staking certificate as collateral to borrow USDC at a 10% annual cost.
Swap the borrowed USDC back into SOL to stake again…
By repeating this cycle, you effectively leverage your initial capital to amplify the yield spread.

Let's Start with Basic Arbitrage on Solana

Core Logic of On-chain Arbitrage

On-chain arbitrage exploits price differences of the same token across different liquidity pools (LPs). For example, if one pool's price fluctuates sharply due to a trade while another lags behind, an arbitrage opportunity arises.

This often occurs with common tokens like wSOL, USDC, and USDT across various AMMs.

Basic Arbitrage Flow:

Monitor price changes / arbitrage opportunities.
Calculate whether a positive profit exists.
Construct the transaction (usually as an atomic transaction).
Bundle and execute the transaction on-chain.

Getting the Best Quotes with Jupiter and Jito

To ensure the optimal arbitrage path and maximum profit, most strategies combine Jupiter (Jup) and Jito.

How it works:

Use Jupiter to get quotes for two reverse trades (e.g., A → B → A).
Calculate potential profit based on the price difference.
Merge both trades into a single atomic transaction and simulate it.

Jito allows you to submit bundled transactions and simulate them before sending on-chain. Failed simulations incur no cost.

⚠️ Note: Frequent API calls to Jito can trigger rate-limiting (like DDoS protection). In quantitative deployment, it's crucial to design a rate control strategy—which we’ll cover later.

Optimization Strategies

To increase the success rate and profitability of arbitrage, consider optimizing in these areas:

Use Flash Loans

Amplify returns with borrowed capital.
Because of atomicity, borrowing and repaying happen within a single transaction—no risk or cost if the transaction fails.

Optimize Compute Unit (CU) Usage

Solana limits CU per transaction.
Lower CU consumption increases the chance of successful execution—especially in high-concurrency environments.

Custom Quote & Routing Logic

Jupiter API requests can be slow.
Implementing your own quoting algorithm and pathfinding logic can dramatically improve speed and increase arbitrage success.

Faster RPC Node Responses

Use high-performance RPC nodes (e.g., private or optimized nodes) to avoid frontrunning and reduce latency.

Why Top Arbitrageurs Don't Use Jupiter

Many users rely on Jupiter Aggregator for optimal swap paths across DEXs, but serious atomic arbitrageurs avoid it.

Atomic arbitrage involves executing all operations within a single atomic transaction, which demands high speed and priority. Professionals typically build their own paths and custom transaction bundles to achieve higher frequency and lower latency.

For example, Wintermute, a leading market maker, sends hundreds of arbitrage transactions per minute. Jupiter isn’t fast or flexible enough for this kind of high-frequency trading.

However, Solana has some randomness—like congestion, dropped requests, and competition in transaction ordering—so even Wintermute doesn’t always win.

👉 This randomness creates opportunities for individual developers: with smart strategy design, fast bundling, and high-performance RPC nodes, it's still possible to win arbitrage opportunities.

On-chain Speedups

Refer to the Mevbot Docs for mainstream on-chain providers:

Pros & Cons of Using Jito

Pros:

Supports atomic bundles: Ensures either full success or failure; even failed transactions cost nothing—ideal for arbitrage and high-frequency strategies.
High validator coverage: Jito is widely adopted, meaning submitted transactions have higher chances of inclusion.

Cons:

Strict TPS Limits: Officially supports 5 TPS per IP, but real-world rates may drop to 1 TPS/IP under heavy load. Each IP is limited to 50 requests/minute.
Signer throttling: TPS limits also apply to the wallet address, so changing IPs alone doesn’t help.
Occasional outages: Jito, acting as a middle layer, can sometimes go down—crippling bundle submissions and arbitrage strategies.

Multi-path Transaction Optimization

To maximize transaction success, bots often broadcast the same transaction to multiple relayers (e.g., Jito and non-Jito validators). This strategy is known as multi-relay submission or multi-path broadcasting.

It helps prevent failures due to single-path congestion.

Role of Nonce Accounts

Solana uses recent_blockhash and nonce to prevent replay attacks.

If you send identical transactions to different relayers, the network may reject them as duplicates.

Solution: Use a Nonce Account

With deterministic nonce accounts, even if transaction contents differ slightly (e.g., different tips), the system will accept them as distinct transactions with the same nonce sequence.

Jupiter's "Both" Mode (Advanced Users)

Jupiter's advanced setting "Both" mode allows:

Simultaneous submission to Jito Relay and standard validators
Jupiter auto-generates multiple versions (e.g., Jito tip + regular tip)
Users sign multiple versions (usually 2) for simultaneous submission

Full Process:

Create and initialize a Nonce Account.
Build transaction logic (e.g., SOL → USDC swap).
Generate two versions using the same nonce.
Sign and send them to Jito and standard relayers.
Only one will succeed; the other auto-invalidates due to nonce usage.

Strategic Advice:

Use Nonce Account to manage atomic multi-path transactions.
Set appropriate priority fees and tips for each provider.
Monitor slot/status to stop broadcasting after confirmation.
Use high-performance RPC nodes and multi-IP dispatching to improve performance and reliability.

Reducing CU Consumption

On Solana, if a transaction's CU cost is very low (e.g., a simple transfer = 300 CU), it can often be included without tips, thanks to the block "backpack algorithm":

Solana fills each block with high-priority, low-CU transactions first.
If your CU is tiny, it’s more likely to be included quickly "as a bonus".

The smaller your CU, the faster your transaction gets in.

Role of Smart Contracts in Arbitrage

To win the PVP arbitrage race, writing your own smart contract is essential.

On Solana, bypassing aggregators like Jupiter requires custom smart contracts to handle the entire arbitrage logic.

Key roles of smart contracts:

Profit Checking and Execution Filtering

Check token balances before/after execution.
Calculate profits and determine if they exceed a threshold.
Revert the entire transaction if not profitable—enforcing the "don’t execute unless profitable" rule.

Multi-hop Arbitrage Execution

For example:

SOL → LAYER → BONK → SOL (3-hop path)

Each step depends on the previous swap’s output.
Smart contracts can encode these steps as multiple instructions in one transaction.

2. Multi-Hop Execution (Multi-Hop, Multi-Instructions)

For example, to perform an arbitrage round:

SOL → LAYER → BONK → SOL

This is a 3-hop arbitrage path, where each step depends on the swap output from the previous one.

In a smart contract, you can write each swap as a separate instruction.

This requires executing multiple swap instructions sequentially within a single transaction.

The key challenge: each step needs to read the output from the previous swap (e.g., the amount of tokens received).

Example:

Transaction content:

Instruction 1: Swap SOL for LAYER (e.g., using Orca)
Instruction 2: Swap LAYER back to SOL (e.g., using Raydium)

In-contract flow:

After Instruction 1, the contract reads the change in LAYER balance (e.g., receives 500 LAYER)
Instruction 2 depends on the actual amount of 500 LAYER before proceeding
Finally, compare the resulting SOL with the initial input + target profit
If the profit goal isn't met, the whole transaction is reverted to maintain atomicity

Popular Solana Smart Contract Frameworks and Their Characteristics

1️⃣ Anchor – The Go-To for Ecosystem Standardization

Pros:

Comes with built-in IDL (Interface Definition Language) and Events, making frontend integration easier
Great compatibility with ecosystem projects like Jupiter, Jito, and Meteora
Development experience is similar to Ethereum's Hardhat/Foundry, making it beginner-friendly

Cons:

Compiled contracts are larger, with higher CU and rent costs
Not suitable for performance-critical arbitrage contracts

2️⃣ Native `solana-program` (Rust SDK)

The most mainstream choice in the community and officially supported

Offers fine-grained control over accounts, compute units (CU), and execution logic

Doesn’t heavily rely on macros or runtime, making it ideal for lightweight, high-frequency arbitrage contracts

3️⃣ `cavemanloverboy/solana-nostd-entrypoint` – Maximum Optimization

Created by core Temporal members (Jito/ITO providers)

Features:

Uses Rust’s #![no_std] mode to fully control memory and logic without the standard library
No heap allocator or logs; extremely efficient execution
Minimal CU usage – perfect for arbitrage contracts targeting the smallest possible block size

Drawbacks:

Very steep learning curve
Requires embedded development experience (e.g., using unsafe, C-style thinking)
High debugging costs and much worse dev experience compared to Anchor

4️⃣ Pinocchio – Official `no_std` Contract Framework

Repo: anza-xyz/pinocchio

Developed by Agave (a new company from Solana Labs)

Write Solana contracts in C to avoid Rust’s compile-time overhead
Huge room for optimization
Official goal: ultra-small, highly-efficient contracts

Features:

no_std and ultra-minimalist
Closer to system-level contract style
Still lacks detailed documentation and has a steep learning curve

Code Example: Reading Token Balance Changes in Contracts

This snippet is a typical method in Solana smart contracts for manually reading an SPL Token account's balance to determine profit before and after a transaction:

let token_amount = u64::from_le_bytes(
    accounts[0].data
        .borrow()[64..64 + 8]
        .try_into()
        .map_err(|_| solana_program::program_error::ProgramError::Custom(line!()))?
);

Why parse balances manually?

Unlike Ethereum, Solana doesn't provide a built-in "balanceOf" style function. You must manually extract the balance field from an account’s binary data.

In SPL Token accounts, the balance starts at byte offset 64, stored as a little-endian u64:

account.data[64..72] = balance field (8 bytes)

Code Explanation:

accounts[0].data.borrow() → borrow the account's data buffer
[64..72] → locate the balance bytes
.try_into() → convert 8 bytes to [u8; 8] for parsing
u64::from_le_bytes(...) → interpret as a u64 little-endian value

Tool Recommendation: Anchor 8byte Database

GitHub: https://github.com/666pulse/solana-discriminator

What is 8byte?

In Anchor, each function call is routed using an 8-byte selector.

In EVM (Ethereum), this is similar to the 4-byte function selector (e.g., 0xa9059cbb = transfer(address,uint256)).

What does the 8byte database do?

It allows reverse-engineering of function signatures from bytecode to identify whether a contract matches known open-source projects.

This is especially useful when a contract isn’t verified on explorers—just analyze its 8-byte selectors.

Meteora – LP Market Making Arbitrage

Lower Protocol Fees = Higher LP Yields

Compared to other DEXs, Meteora charges lower protocol fees for LPs, resulting in higher actual returns for the same liquidity strategy.

Airdrop Incentives = Additional Expected Yield

Meteora offers a long-term points system: providing LP, trading, or mining earns points that are expected to be used for future airdrops.

Even with thin arbitrage margins, these points can boost your total yield.

Developer-Friendly Contracts with Anchor

Built with Anchor: standardized IDL, clear function calls, standardized events

Perfect for LP strategy or arbitrage bot developers—low integration cost, easy debugging, and well-documented

Useful RPC Methods

getTokenLargestAccounts

Purpose: View the top 20 largest holders of a given SPL Token
getLeaderSchedule

Purpose: Query the block production schedule for validators in a specific epoch
getProgramAccounts

Purpose: Query all accounts related to a program (e.g., pools, LP positions, reward accounts)

Querying Your LP Position via `getProgramAccounts`

To find your LP position in a specific pool, use memcmp filters. Solana contract data is serialized with:

discriminator (8 bytes) + pool address + user address

Example Code:

my_position_bytes_prefix := make([]byte, 8+32+32)

copy(my_position_bytes_prefix[0:8], PositionV2Discriminator[:])
copy(my_position_bytes_prefix[8:40], pool_addr.Bytes())
copy(my_position_bytes_prefix[40:72], myaddr.Bytes())

my_positions, err := s.helius.GetProgramAccountsWithOpts(ctx, DImmProgram, &rpc.GetProgramAccountsOpts{
    Commitment: rpc.CommitmentConfirmed,
    Filters: []rpc.RPCFilter{
        {
            Memcmp: &rpc.RPCFilterMemcmp{
                Offset: 0,
                Bytes:  my_position_bytes_prefix,
            },
        },
    },
})

Use Cases:

Query all your LP positions across multiple pools
Display staking/mining positions on frontend
Identify unclaimed rewards for automated arbitrage

Real-Time Pool Trade Tracking via gRPC: Overbought/Oversold Analysis

Use gRPC to subscribe to DEX pool trades and evaluate market sentiment in real-time.

Calculate Overbought/Oversold Indicators

Similar to RSI, OBV, or MACD in traditional finance.

Example (within 1 minute):

Time	Action	Side	Amount (USDC)
12:00:01	swap	buy	10,000
12:00:02	swap	buy	8,000
12:00:03	swap	buy	12,000

→ Total buy = 30,000 USDC, Total sell = 5,000 USDC → Overbought → Possible short/arbitrage signal

Liquidity Beneath the Surface

Many liquidity pools are not publicly listed like on Jupiter—they may be used privately and lack a website or Twitter presence. Tapping into these pools can also yield arbitrage profits.

Example: Wintermute OTC/RFQ SolFi

Analyze One-Sided Liquidity Risk with OKX DEX Tools

Open OKX DEX or a Solana DEX dashboard and find a token (e.g., $ABC) showing:

Liquidity: $1M

But when you inspect the pool:

$ABC: 980,000 tokens (~$980,000)
SOL: 20 tokens (~$2,000)

This creates the illusion of $1M liquidity, but only 20 SOL is actually redeemable—indicating serious one-sided risk.

Lending Platform Arbitrage / Looping Arbitrage (Using Kamino as an Example)

On Kamino, the utilization rate of some stablecoins (such as USDC) is often above 82%, indicating a supply shortage—deposited funds are fully utilized for lending, which results in higher deposit interest rates.

For example:

Asset	Supply APR	Borrow APR
USDC	15%	12%
FDUSD/TEA	15%	12%

In this scenario, the deposit rate is higher than the borrowing rate, which implies that the platform is offering incentives or that there's strong demand for the asset in the current market.

Arbitrage Method: Looping

By leveraging the structural interest rate spread where Supply > Borrow, we can engage in a “looping” strategy:

Deposit USDC to earn interest (e.g., 15%)
Use the deposited USDC as collateral to borrow a portion (e.g., 70%)
Re-deposit the borrowed USDC and borrow again…
Repeat multiple rounds to amplify your principal, thus amplifying your earnings

This method is known as a leveraged yield farming strategy.

Risk Warning: Leverage Amplifies Risk

Liquidation risk: If market volatility causes your collateral value to drop or borrowing interest to rise, liquidation may occur.
Spread risk: If the borrowing rate surpasses the deposit rate, the arbitrage model becomes invalid.
Protocol parameter risks: Changes like reduced LTV, lowered incentives, or updated interest rate models.
On-chain execution cost: Looping requires multiple steps, which incurs gas fees (though Solana is cheap, it can still become congested).

APY ≠ APR, and APR < APY

APR (Annual Percentage Rate) is a simple annual interest rate, not considering compounding.
APY (Annual Percentage Yield) is the actual annual return including compound interest.

Why is APR < APY?

Because:

APR is calculated as a straight percentage over time without reinvestment.
APY assumes reinvestment of interest, where compounding boosts returns over time.

Example:

If a platform offers an APR of 12% and interest is compounded monthly, then your actual APY becomes:

So, even though the stated APR is 12%, the actual annualized yield (APY) is 12.68%.

When doing DeFi arbitrage or yield strategies, it’s better to look at APY, especially for compounding-based strategies.

Atomic Arbitrage / Looping Arbitrage Reflections

On Solana, atomic or looping arbitrage is typically done using Jupiter aggregator, which is developer-friendly but has some critical downsides:

Issues with Jupiter:

Polling mechanism: Based on REST API polling for market quotes—slower response compared to gRPC trade subscriptions, making it hard to catch arbitrage opportunities promptly.
High CPU load: Constant polling and frequent path calculations strain device resources.
Low chance of Jito Bundle inclusion: While atomic execution is supported, Jito nodes are scarce, and rate limits are strict, making real arbitrage success rates low.
Expensive SPAM strategy: Without Jito, some rely on “broadcast spamming” RPCs—hundreds of transactions might fail, but one success is a win; however, gas costs are extremely high.

Optimization Direction:

Custom Aggregator + Smart Contracts

Use a custom-built DEX aggregator for path control and reactive matching.
Combine with efficient smart contract frameworks (e.g., no_std), which consume far less CU than Jupiter, greatly improving arbitrage execution.
Atomicity assurance: Multi-hop transactions executed within the contract ensure either all succeed or all fail—risk is managed.

Final Thoughts

Instead of relying on Jupiter's high-overhead and low-control approach, it’s better to build your own strategy with lightweight contract logic, precisely controlling execution paths and on-chain processes. This increases both the success rate and profit margin of arbitrage strategies.

🧠 Troubleshooting and Resolving Telegram Bot Disconnection Issues: A Practical Pitfall Sharing

Miles — Tue, 22 Apr 2025 16:19:19 +0000

During the development of a Telegram bot for listening to messages from a specific channel, I encountered a strange issue:

After the program ran for a while, it suddenly stopped receiving new messages from the channel, without any obvious error messages.
This left me quite puzzled and delayed the real-time monitoring tasks. In this article, I will go over the troubleshooting process and how I solved it by implementing a "keep-alive" mechanism and an "auto-reconnect" mechanism. I hope this can help those of you who are also developing TG bots.

🚩 Issue Reproduction: Listening Stops Without Errors

At first, I was using a very simple Telethon script to listen to the channel:

from telethon import TelegramClient, events

client = TelegramClient("session_name", TG_APPID, TG_APPHASH)

@client.on(events.NewMessage(chats=CHANNEL_ID))
async def message_handler(event):
    print("New message received:", event.raw_text)

client.start()
client.run_until_disconnected()

Everything worked fine, but after a few hours, the messages suddenly stopped printing. The key issue—no errors! The program was still running but seemed to have "lost connection."

🔍 Initial Troubleshooting: Blocking? Deadlock? Exception?

I suspected that the issue might have been caused by an exception in the message_handler function, so I added a try-except block:

@client.on(events.NewMessage(chats=CHANNEL_ID))
async def message_handler(event):
    try:
        ...
    except Exception as e:
        print("Error:", e)

After a few hours, I finally captured the following error message:

ConnectionError: Timeout

This indicated that the problem lay in the connection between the client and Telegram's servers.

📡 In-depth Analysis: Why the Timeout?

By consulting the documentation, I discovered that Telegram uses its proprietary MTProto protocol for communication, supporting TCP, HTTPS, and other transmission methods. The client and server typically establish a long-term connection via TCP and rely on periodic heartbeat packets to maintain the connection.

However, if:

The client doesn't send requests for a long time
There are no active tasks (such as message uploads or downloads)
Network fluctuations or device sleep

The server might classify the connection as "inactive" and close it.
Reference: Telegram Protocol Documentation, Shunix's Weblog

✅ Solution: Keep-Alive + Auto-Reconnect

To maintain the connection with Telegram, we can employ two strategies:

Send Heartbeats Periodically (Keep-Alive)
Call a method like client.get_me() at regular intervals to show the client is still active.
Auto-Reconnect Mechanism
If the connection is lost, restart the connection using a while True loop and exception handling.

💻 Final Code Implementation (Simplified)

async def keep_alive():
    while True:
        try:
            await client.get_me()  # Heartbeat
        except Exception as e:
            print(f"[Keep-Alive Failed]: {e}")
        await asyncio.sleep(300)  # Execute every 5 minutes

async def main():
    while True:
        try:
            await client.start()
            asyncio.create_task(keep_alive())  # Start keep-alive
            await client.run_until_disconnected()
        except Exception as e:
            print(f"[Reconnection Failed]: {e}")
        await asyncio.sleep(5)  # Wait 5 seconds before reconnecting

if __name__ == "__main__":
    asyncio.run(main())

🔚 Summary

Although the process of solving this issue was somewhat "tedious," it taught me several valuable lessons:

Communication with Telegram requires connection maintenance.
Exception handling is important and can help identify hidden issues.
Long-running bots need self-recovery capabilities (like keep-alive and auto-reconnect).