DEV Community: ctrl

Freeze authority is the Solana honeypot: how to check any SPL token in 10 seconds (free, no wallet)

ctrl — Mon, 06 Jul 2026 09:43:06 +0000

On EVM chains, a scam token hides in contract code — you need a sell simulation to catch it. On Solana the trap is simpler and nastier: it lives in the token's authorities.

The two authorities that matter

Every SPL mint can carry two switches left over from creation:

Freeze authority — whoever holds it can freeze your token account. Frozen tokens don't move: you can't sell, can't transfer, can't do anything. Buys keep working for everyone else, so the chart looks alive while early buyers are already locked in. This is the Solana equivalent of a honeypot, and it needs zero clever code.
Mint authority — whoever holds it can print more supply at any moment, straight into your exit liquidity.

Legitimate memecoins revoke both at launch, and it's verifiable on-chain in seconds. A "community token" whose creator quietly kept freeze authority is not a community token.

Token-2022 added more switches worth checking: balance-mutable and closable account extensions (an authority can edit or force-close holder accounts), transfer fees (a hidden tax on every hop) and transfer hooks (arbitrary code that runs on each transfer).

How to check — three options, all free

1. GoPlus API directly (keyless, CORS-open):

curl "https://api.gopluslabs.io/api/v1/solana/token_security?contract_addresses=<MINT>"

Look at freezable.status, mintable.status, balance_mutable_authority, closable, transfer_fee, transfer_hook, plus holders for concentration and dex for real liquidity.

2. In the browser: I wired exactly those checks into a static page — paste a mint, get a verdict with the flags spelled out: Solana token checker. Runs 100% client-side on public APIs; nothing is stored, no wallet connection.

3. In Telegram: @RugLens_bot does the same scan inline in any chat (plus EVM chains with a live sell simulation, and TON jettons).

The gotcha with minutes-old mints

Public indexers lag a fresh mint by several minutes: metadata shows up instantly, holders and liquidity don't. A naive checker renders that as an all-green "0 issues found" — which is exactly backwards. If holder and liquidity data don't exist yet, the only honest verdict is too new to verify, i.e. risky by default. Wait a few minutes and re-check; a token that can't be verified yet is a token you don't need to be first into.

The 10-second checklist

Freeze authority revoked? If not — out.
Mint authority revoked? If not — out, unless there's a documented reason (stablecoins legitimately keep both; that's what whitelists are for).
Token-2022 extensions: any balance-mutable / closable / transfer-hook flags on a random memecoin — out.
Top-10 holders share and real DEX liquidity — three wallets holding 95% with $800 of liquidity is a rug with extra steps.

None of this tells you a token will go up. It only tells you whether the exit door exists. On Solana, that's the question most people skip.

Stop refreshing job boards: free APIs for remote-job alerts (Remotive, RemoteOK, Arbeitnow)

ctrl — Sat, 04 Jul 2026 08:11:05 +0000

Job hunting for remote positions has a dumb daily ritual: open Remotive, open RemoteOK, open a couple more boards, scroll past everything you saw yesterday, close the tabs. The good listings get hundreds of applicants within the first day, so being early actually matters — and yet most people check once a day at best.

The boring truth is that the underlying data is completely open. Three of the bigger remote-job sources expose free, keyless JSON APIs:

Remotive: https://remotive.com/api/remote-jobs?limit=100 — title, company, category, salary when disclosed, tags.
RemoteOK: https://remoteok.com/api — needs a User-Agent header, first array element is a legal notice, the rest are jobs with position, company, tags and salary ranges.
Arbeitnow: https://www.arbeitnow.com/api/job-board-api — mostly European listings, has a remote boolean you must filter on (the feed includes on-site jobs too).

With those three endpoints, "watch the boards for me" collapses into a small cron job: pull the feeds hourly, dedupe by job id, match new entries against your keywords, send yourself a message. No scraping, no headless browsers, no API keys.

A few gotchas if you build this yourself:

Dedupe across runs, not within one. Persist seen job ids; the feeds re-serve the same jobs for weeks. Seed the seen-set on first run silently, or your first alert will be a firehose of the entire backlog.
Don't trust tags for matching. RemoteOK in particular attaches a near-global tag cloud to every posting — a real-estate QC job tagged golang, medical and engineer at once. Match against title, company and location only, or your "python" alert will ping for gardening jobs.
Normalize timestamps. One source gives ISO strings without a timezone, the others give unix seconds. Pin everything to UTC before sorting, or "newest first" quietly lies.

If you'd rather not run your own cron: I wired exactly this pipeline into a Telegram bot, @RemoteJobRadarBot. /jobs python searches the merged feeds, /watch senior python pings you when a matching job appears (checked hourly, keyword matching with the caveats above already handled). There is also a channel that just streams the freshest listings: @RemoteJobRad.

Free tier covers normal use (5 searches/day, one watch). Either way — the APIs are open, and being the first applicant instead of the four-hundredth is mostly a matter of plumbing.

Where to find brand-new liquidity pools (and the 60-second check that keeps you from getting rugged)

ctrl — Fri, 03 Jul 2026 22:52:35 +0000

Every 100x story starts the same way: someone found a token minutes after its liquidity pool went live. So does every rug story. New pools are where the asymmetric upside lives — and where the vast majority of outright scams live too. This post covers where to actually find fresh pools, and the 60-second checklist that filters out most of the garbage.

Where fresh pools show up first

GeckoTerminal has a new pools page per network. It's raw and unfiltered — you'll see everything, including pools with $30 of liquidity that exist only to appear in this list. The API is free and keyless (/networks/{network}/new_pools), which makes it the best base layer if you want to build your own feed.

DexScreener has a similar new pairs view with better filtering UI (min liquidity, min volume). Their API is also free.

Telegram channels are how most degens actually consume this. Raw firehose channels exist for every chain, but the noise ratio is brutal. I run @FreshPoolsFeed which posts hourly with two filters applied: liquidity above $25k (kills the dust) and FDV below $2M (kills "new pool for a token that's already a top-500 coin" — you're not early to anything with a $300M FDV). What's left is the actual hunting ground: small, fresh, liquid enough to exit.

The 60-second checklist before you touch a fresh pool

A new pool with real liquidity still has maybe a 70–90% chance of being designed to take your money, depending on chain and market phase. Here's what to check, in order of how fast each check kills a scam:

1. Can you sell? The most common trap is still the honeypot: buys work, sells revert or get taxed 99%. Don't trust the contract source — simulate. honeypot.is runs an actual sell simulation on ETH/BSC/Base and reports effective buy/sell tax.

2. Is the contract still mutable? GoPlus (free API) flags proxy contracts, mintable supply, owner-can-change-tax, blacklist functions, trading-pause switches. Any one of these means the dev can change the rules after you buy. On TON, check if the jetton admin is still set — same idea, different mechanics.

3. Who holds the supply? If the top 10 wallets (excluding the pool and burn addresses) hold 40%+, one wallet can nuke the chart at will. GoPlus and tonapi both expose holder breakdowns.

4. Is the liquidity locked or burned? Unlocked LP means the deployer can pull the pool whenever. LP burn/lock status shows up in GoPlus data and on DexScreener's pair page.

5. How old is the deployer wallet? A wallet created yesterday that deployed five tokens this week is a serial rugger. This one's harder to automate but the pattern is common.

Automating the checklist

Running four browser tabs per token gets old fast when you're checking a dozen pools an hour. Options:

Script it yourself. GoPlus + honeypot.is + DexScreener APIs are all keyless. Maybe 100 lines of code for EVM chains. GoPlus alone covers checks 2–4.
Use a bot. I built @RugLens_bot for exactly this workflow: paste a contract address (or tap a token in @FreshPoolsFeed), get the full checklist back in one report — honeypot simulation, contract flags, holder concentration, liquidity status. Works for 7 EVM networks and TON jettons. Source is on GitHub (MIT) if you'd rather self-host. There's also a no-install web version that runs the same EVM checks in your browser.
Wallet built-ins. Some wallets (Rabby, for one) run basic token checks on approval. Good last line of defense, too late as a screening tool.

The honest caveat

No checklist catches everything. A token can pass every automated check and still dump 95% because the "community" was three guys and a meme template. Screening filters out mechanical scams — honeypots, hidden mints, pullable liquidity. It cannot tell you whether anyone will still care about the token tomorrow. Size accordingly.

How to spot a honeypot token before you buy (and automate the whole checklist)

ctrl — Fri, 03 Jul 2026 22:11:33 +0000

Every week someone in a chat I'm in buys a token they can't sell. The pattern is always the same: chart looks organic, Telegram group is buzzing, contract is "renounced" according to a screenshot someone posted. Then they try to sell and the transaction reverts. That's a honeypot, and it is one of the few scams you can reliably detect before putting money in — the evidence is on-chain and public.

Here is the checklist I actually use, and how to automate it.

1. Can you sell? Simulate, don't trust

A honeypot lets you buy but blocks the sell path — usually a hidden condition in transfer() that only the deployer's wallets pass. You cannot see this from the chart, and you can't always see it from the verified source either (obfuscation is an art form).

The reliable way is a buy/sell simulation: fork the chain state, buy the token, immediately try to sell it, and see what happens. honeypot.is does exactly this for Ethereum, BSC and Base — free, no key. If the simulated sell fails or eats 90% in "tax", you have your answer.

2. Read the static flags

GoPlus token security API aggregates most of what you'd check by hand on a block explorer:

Owner powers: can the owner edit balances? Pause transfers? Blacklist you after buying? Take back "renounced" ownership?
Mint: can supply be inflated into your position?
Taxes: a 5% tax is a business model, a 45% sell tax is an exit scam with extra steps.
Proxy contracts: upgradeable logic means today's honest contract can be tomorrow's honeypot.
Deployer history: wallets that shipped honeypots before tend to do it again.

None of these flags alone is a verdict — USDC is a proxy contract, most stablecoins have an admin — but stacked together they tell a story.

3. Check who holds the bag

If the top 10 wallets hold 80%+ of supply (excluding locked liquidity and burn addresses), the price is whatever they decide it is. Holder concentration plus fresh liquidity plus a deployer wallet funded an hour ago through a mixer is a rug with the fuse lit.

4. TON is not exempt

The same failure modes exist for TON jettons, they just look different: mint authority not revoked, admin address still set, transfer-tax jettons, STON.fi blacklists. Fewer tools cover TON, which is exactly why scammers like it right now.

Automating all of the above

Doing this checklist by hand takes ten minutes per token across four websites. I got tired of it, so all of it is wrapped into a Telegram bot: @RugLens_bot — paste a contract address (EVM or TON), get the full report in a few seconds: honeypot simulation, taxes, owner powers, holder concentration, liquidity, scored 0–100 with plain-language flags. It detects the chain automatically via DEX listings, works inline in any chat (@RugLens_bot <address>), and does 5 checks a day free, which is enough for normal degeneracy levels.

Source and self-hosting instructions: github.com/mrvlyouknowwho/ruglens (MIT).

The one rule that beats every tool

A clean report means "no known trap detected", not "this is a good investment". Tools catch mechanical scams — they don't catch a dev who simply dumps on you with a perfectly honest contract. Size positions like the token can go to zero, because it can.

No Telegram? A browser version

If you just want to paste an address and see the verdict without installing anything, there's a web version that runs the same EVM checks entirely client-side: mrvlyouknowwho.github.io/ruglens — no sign-up, no wallet connection, nothing stored. The Telegram bot adds TON support, inline scanning and the fresh-pool feed on top.

Push-and-pray CI is dumb. I built a step debugger for GitHub Actions.

ctrl — Fri, 03 Jul 2026 14:54:59 +0000

You know the loop.

You edit a .yml. You commit. You push. You wait for the runner to spin up. You watch it churn through five green steps and then fail on step six — some path that isn't set, some env var that didn't thread through, a script that behaves differently than you remembered. You tweak one line. Commit. Push. Wait again.

Every iteration of that loop costs you a commit you'll squash later and three-to-five minutes of staring at a log that scrolls on a server you can't touch. The feedback is slow and it's blind: when step six fails, you can't get into the machine at the moment it failed and look around. You just get the corpse in the log.

I got tired of it and built walkflow — a tool that runs your workflow's steps on your own machine, one at a time, and pauses between them so you can inspect, fix, and continue. No commit. No push. No waiting.

What it feels like

$ walkflow
walkflow — .github/workflows/ci.yml · job 'build'

▶ job build — 6 step(s)

┌─ step 1/6: checkout
│  uses: actions/checkout@v4 — not executable in host mode, skipping.

┌─ step 2/6: install deps
│    $ npm ci
│  [enter] run · [s]hell · [k] skip · [q] quit >           # ⏎
│  running in /home/me/app
└─ ok

┌─ step 3/6: run tests
│    $ npm test
│  [enter] run · [s]hell · [k] skip · [q] quit >           # ⏎
FAIL src/auth.test.ts  ✗ token refresh
│  step failed. [r]etry · [s]hell · [c]ontinue · [q]uit >  # s
│  entering shell (/bin/zsh); `exit` to return to walkflow
$ echo $NODE_ENV        # inspect the exact env step 3 saw
test
$ vim src/auth.ts       # fix it right here
$ exit
│  back in walkflow
│  step failed. [r]etry · [s]hell · [c]ontinue · [q]uit >  # r
└─ ok

The important part is the s. When a step fails — or before any step runs — you can drop into a shell in the workspace, with every environment variable the previous steps exported. Not a fresh shell. The exact state that step would have seen: the PATH additions from earlier steps, the values written to $GITHUB_ENV, the working directory. You poke around, figure out what's wrong, fix the file right there, exit, and hit r to retry — and r even offers to open the failing command in $EDITOR first.

The inner loop that used to be "push and pray, wait four minutes" is now seconds long.

"Isn't that what `act` does?"

Sort of, and this is the first question everyone asks, so let me be precise.

act runs your whole workflow locally in Docker. It's great for replaying — top to bottom, start to finish, then it stops. What it doesn't do is pause between steps, drop you into the live intermediate state, or let you edit a failed step and re-run it in place. That's been an open feature request on act for years.

walkflow is built around exactly that missing piece — the interactive inner loop, not the full replay:

	`act`	`walkflow`
Run workflow locally	✅	✅
Pause between steps	❌	✅
Drop into a shell with live step state	❌	✅
Edit a failed step and retry in place	❌	✅
Faithful `$GITHUB_ENV` / `$GITHUB_PATH` threading	✅	✅

They're not really competitors. act answers "does the whole thing pass in a container?" walkflow answers "why is step six broken, and can I fix it without pushing eight times?"

What it faithfully reproduces

I care about this being honest, because a debugger that lies to you is worse than no debugger. walkflow reproduces:

Environment layering: workflow env: → job env: → step env:.
$GITHUB_ENV exports — both KEY=value and the KEY<<EOF heredoc form — threaded into later steps.
$GITHUB_PATH additions prepended to PATH for later steps.
The default step shell (bash --noprofile --norc -eo pipefail), or your shell: override.
$GITHUB_WORKSPACE, $CI, $GITHUB_ACTIONS, per-step working-directory.

What it doesn't (yet) — stated, not hidden

uses: steps (marketplace actions like actions/checkout, actions/setup-node) are skipped with a note. Most are no-ops against your local checkout anyway. Running them with full Docker environment parity is the headline feature on the roadmap.
${{ expressions }} aren't evaluated — steps run with the literal env. if: conditions and matrix are shown, not enforced.

When walkflow hits one of these, it tells you. No silent surprises.

Handy flags

walkflow                       # finds the single workflow under .github/workflows/
walkflow ci.yml --job build    # pick a file and job
walkflow --list                # print jobs and steps, then exit
walkflow --from 4              # auto-run steps 1–3, go interactive from step 4
walkflow --from "run tests"    # ...or select that step by name
walkflow -y                    # run it all, no pausing — a fast local sanity check

--from is the one I reach for most: it fast-forwards through the steps you already trust (accumulating their env correctly) and hands you the controls exactly at the step you're actually debugging.

Install

It's a single Rust binary, no runtime, no daemon:

cargo install --git https://github.com/mrvlyouknowwho/walkflow

MIT licensed. Repo, issues, and roadmap are here: github.com/mrvlyouknowwho/walkflow.

If you live in GitHub Actions and you've ever pushed a commit whose entire message was fix ci (then fix ci again, then pls), I'd genuinely like to know whether this shortens your loop. Issues and reactions welcome.