vik ⚡️

checked all the boxes and then made my own | dev & jack of all trades | building @1tradeio @yuzufinance

[vik ⚡️ @vscorrpio]

found an interesting honeypot ($RIALTO) on @RobinhoodApp today.

i aped it myself, got drained, felt pretty stupid, so i figured i’d reverse it. turns out it was a pretty clean allowance bypass, and you don’t see those every day.

CA: 0xefd3db0271aa579b8f9f1e4ab91a9d17fea1faa9

attacker helper: 0x5e3c1C6F90d35499C40A5f5769822AF2a631d702
attacker: 0x281FF81dF0Eca1F3F7Ba2A48499c7A83D216a2A8

both contracts were unverified, so most of the reversing was done with a mix of decompilers, AI, and manual analysis.

normally an ERC20 works like this:
- alice owns tokens.
- alice calls approve(bob, 100).
- the contract stores that allowance.
- bob can now call transferFrom(alice, someoneElse, 100).

without that approval, transferFrom should revert. that’s basically the entire security model behind ERC20 allowances.

on $RIALTO, transferFrom has another branch.

before it checks the allowance, it loads a value from a hidden mapping in storage slot 0 using msg.sender as the key. if that value is non-zero, the allowance check is skipped completely.

roughly:

if (hidden[msg.sender] != 0) {
// skip allowance check
} else {
require(allowance[from][msg.sender] >= amount);
}

the attacker helper contract had hidden[attacker] = 0x64.

that single storage value effectively made it a privileged spender. it could call transferFrom(holder, attacker, amount) against any holder without ever receiving an approval from that holder.

i also suspect this has a decent chance of slipping past a lot of automated bytecode scanners. most quick scanners look for obvious blacklist logic, owner mints, tax changes, or suspicious selectors. this one hides inside an otherwise normal-looking transferFrom implementation.

they were also actively market making the token. volume looked organic, there were real-looking sells, larger buys getting sold into, then the chart recovered again. the price action looked surprisingly legitimate even though the whole thing was all fake.

since @RobinhoodApp is only on day 2, stuff like this was bound to show up sooner or later. security tooling and risk scoring on new chains usually takes time to catch up, so don’t blindly trust green checkmarks on terminals like @BasedBot which btw great job for working so well on day0 when nobody else was around

stay safe out there.

[vik ⚡️ @vscorrpio]

@clickl3ss incredibly fine read. good job bro

[clickless @clickl3ss]

Robinhood cashcat listing was insider traded. https://t.co/vHAvgEHhoB

[vik ⚡️ @vscorrpio]

@Remembers_xyz goated 🐐

[vik ⚡️ @vscorrpio]

for anyone wondering how this actually worked:

normally, if you open a malicious website, it can’t just read what’s open in your other tabs. browsers are designed to prevent that.

browser extensions are different. once you install one, you’re giving it extra permissions that normal websites don’t have.

in this case, the adobe acrobat extension had a bug that let a malicious website “ask” the extension to fetch information from another tab and send it back. the website couldn’t do it on its own, but it could trick the extension into doing it for it.

the PoC used whatsapp web, but that’s just what the researchers chose to demonstrate. the important part is that the extension became the bridge between the malicious website and another tab that should have stayed private.

that’s why i always recommend keeping your trading browser as clean as possible. if you’re trenching and opening hundreds of random token websites, every extension you don’t actually need is just another thing that could eventually be abused.

[vik ⚡️ @vscorrpio]

⚠️ quick OPSEC reminder for anyone trenching!

the Adobe Acrobat Chrome extension (CVE-2026-48294) had a bug that let a malicious site abuse the extension to access data from other authenticated tabs.

if you have it, update it NOW and you don’t need it, uninstall it.

tbh, this applies to every non-essential extension.

your trenching browser shouldn’t be loaded with random extensions you’ve accumulated over the years as every one of them runs privileged code inside the same browser you’re using to open completely untrusted token websites.

more info on the vulnerability here:
https://t.co/Lg63BIBLdk

[vik ⚡️ @vscorrpio]

@angrymouse_dev @RobinhoodApp i wish I found something like this and not spend literally days to get this synced up, but hopefully this will help anyone looking forward to run RH infra.

i messaged the @RobinhoodApp team as well, might have this included in the official docs as well

[vik ⚡️ @vscorrpio]

Syncing a @RobinhoodApp node from genesis takes many days, and I couldn't find a snapshot to skip it. So I made one and put it on Cloudflare R2 bucket. Free to grab.

~452 GiB, up and running in a couple hours.

instructions here:
https://t.co/q3YTmvoXKW

[vik ⚡️ @vscorrpio]

@Remembers_xyz sickk 🔥

[vik ⚡️ @vscorrpio]

@0xM4x @ProMint_X @Noxa_Fi @ponsdotfamily @vladdotfun was about to write this, but exactly my thoughts here

[vik ⚡️ @vscorrpio]

@militereum Yes they have one, but sometimes does not work very well.
https://t.co/PSzHEmtjT8

[vik ⚡️ @vscorrpio]

found an interesting honeypot ($RIALTO) on @RobinhoodApp today.

i aped it myself, got drained, felt pretty stupid, so i figured i’d reverse it. turns out it was a pretty clean allowance bypass, and you don’t see those every day.

CA: 0xefd3db0271aa579b8f9f1e4ab91a9d17fea1faa9

attacker helper: 0x5e3c1C6F90d35499C40A5f5769822AF2a631d702
attacker: 0x281FF81dF0Eca1F3F7Ba2A48499c7A83D216a2A8

both contracts were unverified, so most of the reversing was done with a mix of decompilers, AI, and manual analysis.

normally an ERC20 works like this:
- alice owns tokens.
- alice calls approve(bob, 100).
- the contract stores that allowance.
- bob can now call transferFrom(alice, someoneElse, 100).

without that approval, transferFrom should revert. that’s basically the entire security model behind ERC20 allowances.

on $RIALTO, transferFrom has another branch.

before it checks the allowance, it loads a value from a hidden mapping in storage slot 0 using msg.sender as the key. if that value is non-zero, the allowance check is skipped completely.

roughly:

if (hidden[msg.sender] != 0) {
// skip allowance check
} else {
require(allowance[from][msg.sender] >= amount);
}

the attacker helper contract had hidden[attacker] = 0x64.

that single storage value effectively made it a privileged spender. it could call transferFrom(holder, attacker, amount) against any holder without ever receiving an approval from that holder.

i also suspect this has a decent chance of slipping past a lot of automated bytecode scanners. most quick scanners look for obvious blacklist logic, owner mints, tax changes, or suspicious selectors. this one hides inside an otherwise normal-looking transferFrom implementation.

they were also actively market making the token. volume looked organic, there were real-looking sells, larger buys getting sold into, then the chart recovered again. the price action looked surprisingly legitimate even though the whole thing was all fake.

since @RobinhoodApp is only on day 2, stuff like this was bound to show up sooner or later. security tooling and risk scoring on new chains usually takes time to catch up, so don’t blindly trust green checkmarks on terminals like @BasedBot which btw great job for working so well on day0 when nobody else was around

stay safe out there.

[vik ⚡️ @vscorrpio]

@tradefeather 🪶

[vik ⚡️ @vscorrpio]

@tradefeather @rialto_xyz 💸

[vik ⚡️ @vscorrpio]

@KienNguyen_NFT @tradefeather - fully working product (tested), corporate branding sitting relatively low; could be undervalued if it gains more traction

[vik ⚡️ @vscorrpio]

@militereum it appears that this pattern is now increasingly being detected by basedbot's audit partner. check this: https://t.co/gTAUXRdUgc

see how they are doing it and try to work around it

best of luck, hit me up if you need help

[vik ⚡️ @vscorrpio]

@Langerius wrote a small article on how they work here
https://t.co/84QdnjchKS

luckily scanners now detect this pattern like smb mentioned before so peeps should be safer now

[vik ⚡️ @vscorrpio]

found an interesting honeypot ($RIALTO) on @RobinhoodApp today.

i aped it myself, got drained, felt pretty stupid, so i figured i’d reverse it. turns out it was a pretty clean allowance bypass, and you don’t see those every day.

CA: 0xefd3db0271aa579b8f9f1e4ab91a9d17fea1faa9

attacker helper: 0x5e3c1C6F90d35499C40A5f5769822AF2a631d702
attacker: 0x281FF81dF0Eca1F3F7Ba2A48499c7A83D216a2A8

both contracts were unverified, so most of the reversing was done with a mix of decompilers, AI, and manual analysis.

normally an ERC20 works like this:
- alice owns tokens.
- alice calls approve(bob, 100).
- the contract stores that allowance.
- bob can now call transferFrom(alice, someoneElse, 100).

without that approval, transferFrom should revert. that’s basically the entire security model behind ERC20 allowances.

on $RIALTO, transferFrom has another branch.

before it checks the allowance, it loads a value from a hidden mapping in storage slot 0 using msg.sender as the key. if that value is non-zero, the allowance check is skipped completely.

roughly:

if (hidden[msg.sender] != 0) {
// skip allowance check
} else {
require(allowance[from][msg.sender] >= amount);
}

the attacker helper contract had hidden[attacker] = 0x64.

that single storage value effectively made it a privileged spender. it could call transferFrom(holder, attacker, amount) against any holder without ever receiving an approval from that holder.

i also suspect this has a decent chance of slipping past a lot of automated bytecode scanners. most quick scanners look for obvious blacklist logic, owner mints, tax changes, or suspicious selectors. this one hides inside an otherwise normal-looking transferFrom implementation.

they were also actively market making the token. volume looked organic, there were real-looking sells, larger buys getting sold into, then the chart recovered again. the price action looked surprisingly legitimate even though the whole thing was all fake.

since @RobinhoodApp is only on day 2, stuff like this was bound to show up sooner or later. security tooling and risk scoring on new chains usually takes time to catch up, so don’t blindly trust green checkmarks on terminals like @BasedBot which btw great job for working so well on day0 when nobody else was around

stay safe out there.

[vik ⚡️ @vscorrpio]

@BagCalls @gumdotfun theres been many attempts for prediction market plays, curious how this will unveil

[vik ⚡️ @vscorrpio]

@TJ_RH_fund i can help with the script if you want

[vik ⚡️ @vscorrpio]

@stacy_muur measuring a chain’s health by transaction failure rate is like measuring a road by how many people miss their exit. you’re mostly measuring user behavior, not the road lol

[vik ⚡️ @vscorrpio]

@TJ_RH_fund @TJCoachMark @TJCoachMark

[vik ⚡️ @vscorrpio]

it's actually kinda hard because for example a normal honeypot would immediately get flagged as it'd either have 100% sell tax or immediately snatch the tokens in same TX which is flagged by scanners immediately

for this particular honeypot (i've kept seeing it since I posted), the "stealing" executes a few blocks after the buy so if you simulate as a normal user, the privileged branch never executes, so the contract behaves like a standard ERC20. you’d have to simulate from the privileged address (or discover it first) to expose the bypass.

suggestion for @BasedBot: this is becoming very frequent on RH and the automated scanner is not detecting those; adding a small feature to track whether the holders' balances' gets sent out of their wallets would go a long way here