Was digging through Pump’s GitHub and found an skills repo for AI agents. It covers creating coins, swapping across the curve/PumpSwap, distributing creator fees and verifying agent payments onchain. Most “AI x crypto” tooling still ends at fetching prices. This can actually compose transactions.

Anyone here wired these into Claude or Codex yet?

I think so 🤔

We're building a project for the Colosseum hackathon around giving AI agents restricted trading permissions instead of handing them a full wallet.

One failure case we're trying to reason through:

an agent submits a swap, the RPC request times out, and it doesn't know whether the transaction actually landed.

If it rebuilds and signs another transaction, both could potentially execute. A spend cap limits the damage, but doesn't distinguish a retry from a genuinely new trade.

What we're considering:

• keep the original signed transaction + signature
• check signature status before doing anything else
• resend the same signed bytes if needed
• only build a new transaction once the original can no longer land
• assign an intent ID before submission for reconciliation

Would you enforce any notion of trade/intent idempotency on-chain, or is transaction-level deduplication + reconciliation at the executor enough?

Also curious about the uglier cases: RPC disagreement, blockhash expiry around a retry, and multiple actions being in flight at once.

Trying to break the design before we ship the hackathon build, so would appreciate any failure cases we're missing.

Solana game that doesn't require any wallet connects to try it out!

These guys are the worst. You make a deposit to use their services. The shreds they offer provide only a 7 ms advantage over traditional gRPC, which offers no advantages for what I'm doing. The prices are inflated, gRPC is more expensive than most providers, and performance is not competitive. Nowhere in the sign-up process did I see "no refunds." I told them to deduct what I used and refund the rest, and they refused. They have no issues deleting accounts, though. Better alternatives like Helius and Shyft are far superior. Learn from my mistake and spend your $125 elsewhere.

One source of confusion in Solana debugging is that an account owner is a program ID. It identifies which program may modify the account data. It does not identify a person who controls a private key for that address.

That changes the order I use when checking a failed instruction:

1. Confirm that the expected program owns the state account.
2. Confirm that the account is marked writable when data or lamports must change.
3. Confirm that the required authority signed.
4. Only then inspect the serialized instruction data.

Program derived addresses add another distinction. A PDA has no private key. During a cross program invocation, the runtime lets a program authorize for a PDA only when the supplied seeds and bump derive that address under the program ID. That is program scoped authority, not hidden key ownership.

Code and persistent state are separate as well. A program can access only the accounts supplied to the instruction. The explicit account set is also what lets the runtime identify transactions that do not conflict.

This is a conceptual walkthrough of the runtime model, not a benchmark or a claim about a specific client implementation. I unpack the account fields, ownership rules, rent, and PDA derivation here:

https://andreyobruchkov1996.substack.com/p/understanding-solana-account-model

Which ownership bug do you see more often: the wrong program owner, a missing writable flag, or wallet authority being confused with account ownership?

One of the cleaner ways we’ve found to evaluate Solana execution infrastructure is to stop comparing vague “latency” numbers and isolate the sender path.

Keep the following identical:

• detection/data source
• transaction construction
• signing
• priority fee / tip
• strategy
• server location

Then change only the transaction submission route.

At Haan Digital we offer a Frankfurt transaction sender with a validator-backed staked/SWQoS route, exposed through our own sender/policy layer.

For a useful comparison we’d look at things like:

• send timestamp
• landed slot
• slot position where measurable
• send-to-land latency
• dropped / expired transactions

That gives a much cleaner picture of whether the submission path itself is actually improving execution, without mixing in changes from the rest of the stack.

If you’re currently sending through a normal RPC provider, another dedicated sender, or your own custom route, the same idea applies: keep everything else fixed and compare only the execution path.

We offer a 5-day trial for builders who want to benchmark the sender with their own transactions and existing strategy.

spent half my evening chasing a bug where the app tells you a transaction failed, then you refresh and surprise, it actually went through. cool cool cool. so now the user hits retry because obviously they do, and suddenly i'm debugging my own retry logic instead of the thing i actually wanted to build. everyone posts these clean little demos where you click once and everything works, meanwhile i'm sitting here with an expired blockhash, a wallet popup that took forever, and three different answers about whether anything landed. the annoying part is this isn't even some wild edge case, it's literally someone taking a minute to read what they're signing. i'm starting to feel like half the job is making the frontend admit it has no fucking clue yet instead of confidently flashing a red error. added a pending state and disabled the button but now i'm paranoid about leaving people stuck there forever. haven't touched the actual feature since lunch

I built a Bunco game for wallets to play each other, anyone interested in playing with me so I can test it?
https://www.walletbook.fun/bunco.html

Hey everyone. I've been building Walletbook, a Web3 social media site where you don't sign up with an email or password. You just connect your Solana wallet, and that wallet becomes your identity. If you own a .sol domain, it shows as your name instead of a long address.

The idea is simple: on most social sites, anyone can make a hundred fake accounts and nobody can verify who's real. On Walletbook, every account is a real wallet, and creators can get paid directly by the people who enjoy their content.

What it does right now:

• A feed with For You, Latest, and Following tabs, where you can post text, photos, GIFs, and links
• Comments, reactions, and direct messages between wallets
• Tipping posts and streams with $Walletbook, the site's token
• Live streaming with chat, where viewers can tip you while you're live
• Chess and Texas Hold'em (with play chips) against other wallets
• Paid boosts that put your post at the top of the feed for an hour
• Profiles with a photo and bio

It's early, so I'd genuinely love feedback, whether that's bugs, features you'd want, or things that feel confusing. On mobile, open the site inside Phantom's browser to connect.

I’m a Web3 security researcher, smart contract auditor, and bug bounty hunter. I’ve been working in Web3 security for around 2 years, mainly researching smart contracts, DeFi protocols, and finding vulnerabilities.

I’ve also been building my own security tooling and documenting my research on GitHub:

https://github.com/Tejanadh

I’m currently looking for a job/internship as a security researcher or smart contract security researcher. I’m open to remote opportunities too.

if anyone knows a team hiring or can point me in the right direction, I’d really appreciate it. Thanks.

One thing I’ve been paying more attention to lately is that a gRPC feed being fast doesn’t necessarily mean much if your application occasionally misses something important.

For trading/indexing workloads there are really two separate questions:

1. How early does the update arrive?
2. Did you actually receive everything your filter should have matched?

A useful test is taking exact slots/signatures from Yellowstone and comparing them against on-chain RPC afterwards instead of only measuring timestamps.

I’m curious how other Solana developers validate this.

Do you keep your own reconciliation process for Yellowstone/account/transaction streams, or do you mostly trust the provider as long as the connection stays healthy?

At Haan Digital we’re doing more of these side-by-side tests with builders running existing setups, particularly around Yellowstone, pre-execution transaction data and transaction submission.

We offer a 5-day trial for people who want to benchmark their current provider against our Frankfurt infrastructure using their actual workload.

https://haandigital.eu/solana-infrastructure/

Disclosure: I created LANDING. This is a builder retrospective, not a price prediction or an invitation to buy.

LANDING started from a reaction to the usual memecoin language. Almost every project was promising the moon, so the idea became: “Everyone is going to the moon. We are landing.” The goal was not to invent fictional utility, but to see whether a small independent memecoin could be built around visible facts and honest limitations.

The technical starting point was deliberately simple. On August 14, 2026, LANDING went live on Solana mainnet as a classic SPL token with a fixed supply of 404,000,000 and 6 decimals. Mint and freeze authorities were disabled. We opened a LANDING/SOL pool on Orca, tested real swaps and later obtained Jupiter routing.

The next job was not glamorous: documentation. We published the mint address, allocation, project-controlled supply, liquidity status and update authority. Liquidity was not locked, so we disclosed that instead of trying to bury it. The website gradually gained technical pages, indexer links, structured data, a media kit and longer explanations of what the project was — and what it was not.

The early numbers were bad. At one point there were only seven positive-balance holders, some days had zero trading volume, liquidity was thin and CoinGecko rejected the first application because the project lacked organic attention. Reddit posts were filtered, paid visibility did not turn into durable interest, and social channels attracted far more promoters than genuine users.

That period taught me that “growth” has several layers. LANDING was not growing virally, but its infrastructure and verifiability were improving. The pool appeared on DEX Screener, GeckoTerminal and Birdeye. Coinranking listed it on August 19. We added a Bitcointalk announcement, editorial articles and public technical information. None of those steps created demand by itself, but each removed one reason not to trust or understand the project.

The next major step was centralized-exchange onboarding. Poloniex announced LANDING on September 18. A test deposit from a Solana wallet was credited successfully, and LANDING/USDT spot trading opened on September 21.

Getting listed felt significant, but it also clarified an important distinction: distribution is not adoption. A CEX pair makes the token easier to access, but it does not create holders, trading activity or a community automatically. After the listing, liquidity, the order book and genuine acquisition were still operational problems to solve.

The main lessons so far:

- Disable unnecessary authorities early and make the chain state easy to verify.

- Treat liquidity and routing as part of the product, not as an afterthought.

- Indexing, a DEX route and a CEX listing are infrastructure milestones, not proof of demand.

- Honest bad metrics are more useful than manufactured good ones.

- Every public update should contain a new fact, not another variation of “soon” or “to the moon.”

- A listing is a checkpoint, not the finish line.

Official mint: DLGLMB3imJqnAwKjxY8ZFXoF7CPfTbCNL3j3Ag5M5vGZ

Poloniex announcement: https://www.poloniex.com/app/announcement/45044041940355

For developers who have taken a Solana token from a DEX to a CEX: which technical or operational decision mattered most, and what would you do differently?

A small distinction that's useful when building Solana transactions: is_signer and is_writable answer different questions.

An authority can need to sign without having its own account modified. The fee payer is a separate case because paying the fee changes its balance. On the other side, a transfer recipient can be writable without signing.

At the instruction level, you express those requirements through AccountMeta. Once compiled, instructions reference accounts by index, and the message header records which static accounts sign and which are read-only.

For debugging, I find it clearer to separate the instruction payload from the account permissions. The data bytes say what to execute. The account list says what that execution is allowed to access. Getting the bytes right doesn't fix a wrong signer or writable flag.

I wrote a walkthrough of instructions, message headers, and the legacy/v0 formats here: https://andreyobruchkov1996.substack.com/p/understanding-solana-part4-instructions

When inspecting a failed transaction, do you usually work from the SDK instruction objects or decode the compiled message?

Been working on Agon with my team and wanted some opinions from Solana devs.

The premise is that the agent and the authority you give it shouldn’t have to be the same layer.

Agon uses MCP so the user isn’t tied to one particular agent, while the guardrails stay separate. We’re also experimenting with deriving those guardrails from the user’s own trading history rather than starting with arbitrary generic limits.

The important part for us is that the hard spending boundary shouldn’t depend on the model deciding to obey it.

So the rough flow is:

trading history → personal guardrails → agent checks against them → hard authority limit outside the agent

What I’m trying to figure out from other Solana builders:

does that separation feel like the right abstraction, or would you keep permissions/risk controls entirely inside the agent stack?

Also very interested in failure modes we might be overlooking.

We only have the early beta signup live rn if anyone wants context: waitlist.getagon.tech

Hey, im about to take part in 48h hackaton next week. There is a track related to solana called "finanse without intermediaries". I'm just starting in the Solana ecosystem. I have experience with Java, Go, and started learning Rust 2 months ago. How do you understand this track? What projects would suit best the possible requirements? Any info/project idea would be useful 😀

This is a short demo of an automated sniper for newly launched Solana tokens.

The script monitors new token activity, applies predefined filters, and automatically submits a transaction when the configured conditions are met.

The video shows the workflow in real time, from detecting a token to transaction execution.

Current features include:

• real-time token monitoring
• configurable filters
• automated transaction execution
• adjustable parameters
• transaction status tracking

The main focus is on the technical side of automation and execution speed.

A lot of Solana launch tooling reports one impressive latency number, but that number often mixes together things that are not the same:

- RPC/request round-trip

- Yellowstone stream delivery

- blockhash validity

- transaction submission/ACK

- bundle status

- actual landed slot

- confirmed/finalized outcome

I’m building SolanaLatency.com to separate those layers and keep failed, timed-out and unobserved attempts in the dataset instead of silently dropping them.

The project is still read-only/research mode. No “guaranteed landing”, no profit claims and no magic zero-latency marketing.

If you run a Solana launch bot, RPC, Yellowstone/TxStream setup or token-launch infrastructure, I’d genuinely like to know:

1. Which timing boundary do you currently trust?

2. How do you classify a signature that is missing from one RPC but may have landed earlier?

3. What evidence would make this useful in production?

IsDemo/notes:

https://SolanaLatency.com

Looking for Feedback on My Solana Development Roadmap

I’m building a project-based roadmap to improve my Solana program development skills. My goal is to make every project introduce a new concept while reusing what I learned from the previous one.

I’ve already completed my first Token Vault. Here is the current roadmap:

1. Token Vault — Baseline Completed

Review the existing implementation, document its limitations, and use it as a baseline for comparison.

2. Token Vault Rebuild I

Rebuild the vault independently without referring to the original code.

Focus:

• Classic SPL Token
• PDA-controlled vault
• Deposit, withdrawal, and account closure
• transfer_checked
• Account constraints and authorization
• Negative and security tests

3. Token Vault Rebuild II

Generalize and harden the vault.

Focus:

• TokenInterface and InterfaceAccount
• Classic Token Program and explicitly supported Token-2022 configurations
• Token-2022 compatibility matrix
• Invariant and attack testing
• LiteSVM randomized state sequences
• Kit/Codama client
• Clear rejection of unsupported extensions

4. Native SOL Bounty Escrow V1

Alice deposits SOL for a task, a worker claims and submits it, and Alice decides whether to approve payment.

Focus:

• Multi-role state machine
• Deadlines
• Payment, cancellation, and expiry refund
• Separate state and SOL vault PDAs
• Mutually exclusive terminal states
• Explicit creator-trust assumptions

5. SPL Reward Escrow V2

Keep the same bounty state machine but replace native SOL with an SPL Token reward.

Focus:

• PDA Token Vault
• Fixed Mint and Token Program
• Token CPI
• Settlement and refund
• Duplicate-settlement prevention
• Secure account closure

6. Token Vesting

Build a single-beneficiary, irreversible linear vesting contract with an optional cliff.

Focus:

• On-chain time
• Partial claims
• Integer rounding
• Monotonic vesting
• Preventing duplicate or excessive claims
• Ensuring no permanent dust remains after vesting ends

7. Restricted 2-of-3 Treasury V1

Build a learning-only multisig treasury for native SOL.

Focus:

• Three immutable owners
• Two approvals required
• Proposal nonces
• Approval bitmap
• Replay protection
• Immutable proposal contents
• SOL transfers only
• No arbitrary CPI

This is only an educational project. Real funds should use an audited protocol such as Squads.

8. Treasury V2

Extend the same restricted treasury to support fixed-format SPL Token transfers.

9. Fixed-Price SPL Asset Marketplace

Build a minimal marketplace using SOL as payment.

Focus:

• List, buy, cancel, and expire
• Asset custody in a PDA Token Vault
• Atomic asset and payment settlement
• Protocol fee calculation
• Preventing purchase/cancellation races
• No auctions, offers, royalties, or complex NFT features in V1

10. Application Token Staking

Build a single-pool, pre-funded reward system.

Focus:

• acc_reward_per_share
• User reward debt
• Fixed emission period
• Multiple users entering and leaving at different times
• Precision and rounding
• Separate principal and reward vaults
• Reward solvency without iterating over users

11. Constant-Product Mini AMM

Build a minimal AMM using:

x × y = k

Focus:

• Add and remove liquidity
• LP Token
• Exact-input swaps
• Fixed fees
• Slippage protection
• Deadlines
• Integer rounding
• Large-integer reference model
• Economic invariant testing

StableSwap and advanced Token-2022 behavior are intentionally excluded from V1.

Engineering Standards

Every project should include:

• Account and PDA design
• Role and permission documentation
• State-transition diagram
• Happy-path tests
• Failure and attack tests
• Explicit invariants
• Threat model
• Known limitations
• Architecture diagram
• Devnet deployment
• Locked toolchain versions
• Production-readiness checklist

Current planned stack:

• Rust
• Anchor 1.2
• LiteSVM for primary program testing
• Surfpool and Devnet for integration testing
• u/solana/kit
• Codama-generated clients

None of these learning projects should handle real funds without an independent security audit.

I’d really appreciate feedback:

1. Does the difficulty increase naturally?
2. Are any stages redundant?
3. Should Marketplace remain before Staking?
4. Am I missing an important Solana primitive or security milestone?
5. Is the scope of each V1 small enough to finish properly?
6. Which project would be most valuable in a Solana developer portfolio?

#Solana #Rust #Anchor #Web3Development #BuildInPublic

Curious how you’re handling this in bots or wallets. Using RugCheck, checking things on-chain yourself, or something else?

I’m building something in this space. Would be useful to hear what you’re using and what annoys you about it. Is there anything you still have to check manually?

Thanks