标签：#solana

A honeypot is the cleanest way to drain a trading bot on Solana: the token lets you buy , but there is no way to sell . Your agent spends real USDC, receives tokens, and then discovers the exit is welded shut. The position is worth zero and there is nothing to do about it. Honeypots don't show up on a price chart — the chart looks great, because everyone can buy and nobody can sell. You only find out at exit. So the check has to happen before the buy. What makes a Solana token a honeypot No live sell route — there is simply no route back to USDC/SOL on any DEX. The most common case. Transfer restrictions — Token-2022 extensions like transferHook or pausable let the creator block transfers (and therefore sells). Freeze authority — the issuer can freeze your account so the tokens can't move. Detect it in one call RugCheck AI is a remote MCP server. Point your agent at the endpoint and ask before any buy: simulate_sell("<mint>") -> { sellable: true|false, verdict: "..." } A token with no live sell route comes back sellable:false — that's the honeypot, even when nothing on-chain formally blocks the sell yet. For the full picture in one shot: scan_token("<mint>") -> { verdict: SAFE|CAUTION|DANGER, safety_score, sellable, risks: [...] } Or simulate the whole round-trip at your real size: simulate_trade("<mint>", 100) -> { buyable, sellable, exit_usd, round_trip_loss_pct } A honeypot shows buyable:true, sellable:false. A healthy token shows a small round-trip loss (slippage) and sellable:true. A real one I scanned a fresh pump token on 2026-06-17 (re-run to verify): scan_token returned DANGER, score 20 — no live sell route, 100% of supply held by a single wallet, $0 liquidity. An agent that bought it could never get out. That verdict is available before the buy, even though the token is too new to be indexed anywhere else. Wire it into your agent It's a standard Streamable HTTP MCP server. In Cline / Claude Dev, add an mcpServers entry named rugcheck-ai pointing at the end

If you have made it this far in 100 Days of Solana, you have been working in JavaScript and on the command line. You have been calling RPC methods, building instructions, signing transactions, and reading and writing account data in JavaScript, and most recently minting and sending tokens and NFTs from the CLI. Either way, you have been driving Solana with tools that let you assign a value and move on with your life. Soon the ground shifts. You are going to open a file called lib.rs , and it is going to be Rust, and for a day or two it is going to feel like you forgot how to program. That feeling is normal, it is temporary, and it is not a sign you are in the wrong place. Here is the thing nobody says out loud: you do not need to learn all of Rust to write Solana programs. Rust is a big language with a steep reputation, but the slice of it that shows up in an Anchor program is small and repetitive. You will see the same handful of patterns on almost every line. Learn those patterns and the wall turns back into a floor. This post is that handful. Not a Rust course, just the parts you need to read your first Anchor program and understand what every line is doing. Next week we start Arc 9, the Anchor introduction, where this all becomes real. This week is about making the language stop being scary before you get there. Why it feels like a wall JavaScript is dynamically typed and garbage collected. You write const x = 5 , you never tell anyone it is a number, and when you are done with it the runtime quietly cleans up. The language trusts you and sorts out the consequences at runtime, which is why a typo surfaces as undefined is not a function three minutes into a demo. Rust is the opposite philosophy. It is compiled and statically typed, so every value has a type the compiler knows about before the program ever runs, and it has no garbage collector, so it tracks who is responsible for every piece of memory through a system called ownership. The trade is blunt: Rust mak

Before this week, NFTs on Solana weren't new to me. I've previously worked with Programmable NFTs ( pNFTs ) and even built projects that integrate them. However, most of my experience was centered around the Metaplex ecosystem, so I tended to think about NFTs through that lens. What surprised me during this learning arc was discovering how much can be built directly with Token Extensions. By creating NFTs from the token level upward, I gained a much deeper understanding of the underlying primitives that make digital assets work on Solana. The Mental Model: What Is an NFT on Solana? As developers, we often interact with NFTs through SDKs , frameworks , and marketplace tooling. Those abstractions are useful, but they can hide what's actually happening on-chain. This week helped me simplify the model: An * NFT * is fundamentally a token mint configured with: A supply of one Zero decimals Metadata describing the asset Optional relationships to collections or groups Using Token Extensions, many of these capabilities can be attached directly to the token itself rather than relying on additional programs or infrastructure. That shift in perspective was one of the biggest takeaways from this challenge. What I Built Over the course of this arc, I created an NFT on Solana Devnet using Token Extensions and explored several capabilities that I had never implemented directly before. The process included: Creating a mint configured as an NFT Adding metadata using the Metadata Extension Minting a single token Creating a collection using the Group Extension Associating the NFT with the collection through the Member Extension Auditing the account structure and extension data on-chain Updating metadata after the NFT had already been created One of the most valuable parts of the exercise was inspecting the accounts directly instead of relying solely on SDK abstractions. For example: spl-token initialize-metadata \ <NFT_MINT> \ "My First NFT" \ "MNFT" \ https://example.com/metadata.jso

On April 1, 2026, Solana's largest decentralized perpetual futures exchange Drift Protocol suffered an attack, losing approximately $285 million . This is the second-largest DeFi hack of 2026 (behind KelpDAO's $292M attack the same month). Together, these two incidents totaled $577M — 76% of all DeFi stolen funds in 2026 . Key Finding : This was not a smart contract vulnerability. The attacker penetrated protocol personnel through social engineering , used Solana's durable nonce feature to pre-sign malicious transactions, and drained the entire treasury in 12 minutes . Mandiant confirmed the attacker as North Korean state-sponsored APT group UNC6862. ⏱️ Attack Timeline Time Event 6 months prior North Korean hackers establish fake trading company identities, attend crypto industry events Weeks prior Operatives attend crypto conferences in person, build deep trust with Drift contributors Late Feb - Early Mar Telegram group discussions about trading strategies, posing as partners Dec 2025 - Jan 2026 Fake company "Ecosystem Vault" builds partnership with Drift, deposits $1M+ Feb - Mar Attackers gain access to some contributors' code repositories Mar 23 Create 4 malicious wallets using Solana durable nonce feature Mar 27 Security Council migrates to 0-second timelock , removing safety buffer Apr 1, 16:06:09 UTC Execute pre-signed malicious transactions 16:06 - 16:18 UTC Treasury completely drained in 12 minutes Post-Apr 1 Funds swapped via Jupiter, bridged to Ethereum via CCTP, mostly dormant 🔧 Attack Technical Analysis Initial Penetration The attackers used a multi-layered social engineering + technical infiltration combination: HUMINT Operation Spent months building credible identities, attending global industry events Used intermediaries rather than direct contact (classic Lazarus tactic) ZachXBT noted this layered identity structure is a hallmark of Lazarus operations Malicious Code Injection Shared code repositories containing malicious code Exploited unpatched VSCo

I spent 7 days learning Solana token extensions. Here's what clicked, what surprised me, and the code you need to build tokens that can't be traded but can be revoked. The Problem (In Web2 Terms) Imagine you work in HR. You issue an employee a digital badge proving they're a certified security officer. Here's what you'd want: The badge stays in their wallet — they can't trade or sell it Only they can use it If they leave the company or fail a compliance check, you can revoke it silently without their permission The badge metadata (name, symbol, type) is on-chain and permanent You could build this with centralized databases and APIs. On Solana, it's just three extensions on a token mint . What Are Token Extensions? Solana's Token-2022 program lets you attach additional behaviors to any mint at creation time. Think of them like middleware for tokens. Before extensions, every token was the same — a mint with supply and decimals, token accounts holding balances, and transfer instructions. Extensions let you add rules on top : Extension What It Does Use Case Transfer Fee Charge a percentage on every transfer Protocol revenue, marketplace commissions Non-Transferable Make tokens unmovable after minting Soulbound badges, credentials, memberships Permanent Delegate Let the issuer burn tokens from anyone Revocable credentials, subscriptions with expiry Metadata Store name, symbol, URI on-chain Self-describing tokens, no external API needed Default Account State Freeze all new accounts by default Compliance gates, KYC verification The critical rule: extensions must be declared at mint creation . You cannot add them later. This forces you to think about your token's full lifecycle before deploying — which is good design discipline. The Journey: Three Combinations That Matter Over the past week I built three different token types. Here's what I learned from each. Day 34: Transfer Fees (The Marketplace Token) A token that charges 1% on every transfer, withheld automatically and

How combining Non-Transferable and Permanent Delegate extensions changed my understanding of digital ownership on Solana. Imagine earning a high rank in an online game. You can use it. You can benefit from it. Other players can see it. But you cannot transfer that rank to someone else. If you break the game's rules, the game company can revoke it. And if the game gets acquired by another company, authority over that rank can be handed over to a new administrator. That was the closest mental model I found for understanding one of the most interesting things I built this week on Solana: a credential token using Token-2022 extensions. What are Token Extensions? One thing I've learned during this phase of the challenge is that Token-2022 is not just about creating tokens. It allows you to define behaviors directly at the token level through extensions. Instead of relying on application logic to enforce rules, the token program itself can enforce them. For this experiment, I combined two extensions: Non-Transferable — prevents ownership from being transferred to another wallet. Permanent Delegate — gives a designated authority the ability to manage the token even after it has been issued. Individually, those are useful. Together, they create something that behaves less like a currency and more like a credential. The Transfer That Was Supposed to Fail After creating the token, I tried transferring it. spl-token transfer Gn5PZzwDENvpQESaFwgVqzCUFba5sSka59iLtjFTYNvz 1 $THIRD_PARTY \ --owner ~/recipient-wallet.json \ --fee-payer ~/.config/solana/id.json \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --fund-recipient --allow-unfunded-recipient The result: Recipient: ErYcpQYcpdoaaiufrB3MqQE2QaVEhoACZGcssppszPpY Recipient Token Account: 8CvyoKt11UbkWYRVXey6UKK2gqQcvVvbh9Lv3crzo8C3 Funding ATA: 8Cvyokt11UbkWYRVXey6UKK2qqQcvVvbh9LV3crz0803 Status: ❌ Transaction failed during simulation Error: Transfer is disabled for this mint (Token-2022 restriction) What I liked a

If you have been following the 100 Days of Solana challenges, you have already worked with tokens. You created mints, set up token accounts, transferred SOL, and explored token extensions. But there is a distinction that comes up constantly in web3, and understanding it properly will change how you think about everything you build going forward. Fungible and non-fungible tokens. You have probably heard these terms before, especially NFTs. But what do they actually mean on Solana, and how does the same token system handle two very different concepts? What makes something fungible Fungible just means interchangeable. One unit is identical to another unit. If I have 10 USDC and you have 10 USDC, ours are exactly the same. It does not matter which specific USDC tokens I hold because they are all worth the same and behave the same way. We could swap them and nothing changes. This is how most things you are used to work. A dollar bill is fungible. A liter of petrol is fungible. One unit of SOL is the same as any other unit of SOL. When you built token transfers in the challenges, you were working with fungible tokens. You did not need to care about which specific tokens moved, just how many. Fungible tokens are used for currencies, stablecoins, utility tokens, governance tokens, loyalty points, in-game currencies, and anything where the quantity matters more than the individual unit. What makes something non-fungible Non-fungible means unique. Each token is different from every other token, even if they come from the same collection. If I have NFT #42 from a collection and you have NFT #87, those are not interchangeable. They might have different images, different properties, different rarity, or different utility. Think of it like event tickets. Two tickets to the same concert are not the same if one is front row and the other is in the back. They came from the same event, but each one is distinct. Non-fungible tokens are used for digital art, collectibles, membership pa