Tom · SŌGŌ

Building @sogoterminal Non-custodial Hyperliquid perps in TG.
Group owners earn a share of the fees their members' volume generates.

[Tom · SŌGŌ @0xtomdev]

my builder wallet has 174 dollars in it and its down 7.

anyone can look. its onchain, its the same address every user approves.

thats not a bad look, thats the point. i test the money path with my own money

first and i keep it small enough that a bug costs me a coffee instead of a
customer

the day i hide that address is the day something went wrong

[Tom · SŌGŌ @0xtomdev]

saw your answer above, that changes my read and probably for the better.

if backfill is meant to cover historical posts, then people still stuck three weeks later means the backfill isnt reaching them, not that its missing. thats a narrower thing.

the bit im looking at is your own line, "click reconnect x (if it appears)". ..,,,

if the backfill is triggered by that flow, then anyone whose auth never broke never sees the button, so they never get a replay. their token is fine, their posts just sat unmatched during the window, and theres nothing for them to click. from their side it reads as "tracking ready but nothing refreshed", which is exactly what people are reporting.

if thats it, the fix is decoupling the replay from the reconnect trigger so it can be run for an account without an auth event. could be wrong from out here, but it fits the reports better than lag does.

[Tom · SŌGŌ @0xtomdev]

@SolOpperatoooor future me keeps telling me to ship the thing instead of tweaking it for the fourth time. ..

still not listening

[Tom · SŌGŌ @0xtomdev]

that cashtag format catch was a good one.

one thing worth checking if people are still stuck. someone in discord reported follower and following counts updating fine while post tracking sits frozen.

same token, same quota, same app...

that pretty much rules out api lag, since a rate limit would starve both paths, not one.

which leaves the matcher or the cursor. and if the matcher was rejecting posts before your fix, the fix only helps posts that come in after it. anything in the rejected window stays unmatched forever unless something replays it. "no recent post to refresh" is what that looks like from the users side, the timeline is fine, the matcher just never accepted anything in that gap.

could be off, only seeing this from outside.

......but the follower vs post asymmetry is the bit that made me look twice.

[Tom · SŌGŌ @0xtomdev]

Three perp products this year have pitched the same thing.

Find the high signal traders.

Rank them.

Let everyone else follow.

It is a good idea with a hard problem underneath it. Before anyone follows
anyone, you have to convince a stranger that your leaderboard means something.

That is a cold start on trust, and you cannot ship your way out of it.

Telegram groups solved it a decade ago and nobody called it a product.

The person posting calls is already the high signal trader, to the fifty
people who chose to be there.

The ranking happened.

It just happened socially,
in a group chat, without a leaderboard.

Building discovery is the expensive path.

The cheap one is admitting it
already exists somewhere else, and plugging into it.

[Kaiz 🐂🀄️ @Kaiz_294]

[Social trading could be crypto’s biggest consumer product]

“Social trading is definitely where everything is going.”

“If you can figure out who’s high signal as a trader, that’s the edge.”

“We want it all localized in one place.”

“TradingView lets people share ideas. We want a place where you discover alpha and trade.”

@BullpenFi is built around one simple idea: finding signal, not noise.

Instead of tracking wallets one by one, users can see who’s generating real alpha, what they’re trading, the thesis behind each position, and how those trades evolve over time.

@blknoiz06 sees Bullpen as more than a crypto leaderboard.

The long term vision is one platform where stocks, commodities, and crypto traders coexist, making it easier to discover high signal traders and execute from the same interface.

[Tom · SŌGŌ @0xtomdev]

Day 21 on mainnet and the worst bug I shipped was a division.

I had a volume number on my own dashboard that was wrong by roughly a factor of two.

I was backing it out of a fee figure. Fees land on every fill at the venue rate. My event log counts opens only.

Two denominators, one division, one number I read as fact for days.

Nothing crashed. Nothing alerted. It just sat there being wrong while I made decisions on it.

The bugs that hurt are not the ones that throw.

[Tom · SŌGŌ @0xtomdev]

non custodial is a word people use without checking.

the test is simple. can the thing holding your session key move money out.
if yes, its custodial with extra steps.

theres only one honest answer and most products avoid giving it

ask any of them directly and watch what happens

[Tom · SŌGŌ @0xtomdev]

builder fees mean my incentive is volume, not spread.

i dont win when you lose. i win when you trade.

took a long time to find a model where those two point the same direction

most of them dont

[Tom · SŌGŌ @0xtomdev]

yep thats the exact hole. weve had to stash leverage at order time and fall back to activeAssetData when its missing, cause the fill just doesnt carry it. works but its a self heal not a source of truth.

the other gap on that endpoint is liquidation fills, they come back through a different path than normal closes and a naive parser drops them. if those are missing from a sample every winrate in it reads high and nothing looks broken.

re HFT, agree theyre uncopyable, but style drift on medium timeframe traders is the harder analytics problem imo. thats where margin data would actually matter

[Tom · SŌGŌ @0xtomdev]

My test suite was writing into the real data directory.

Not production, but the same directory the local service reads. So a failed run could leave state behind that the next thing to boot would read as real.

I found it because a test failure changed behaviour in a completely unrelated command.

Fix is boring. Temporary state directory per suite, injected through the same environment variable the service already uses.

The interesting part is that the variable existed the whole time. I had built the isolation mechanism months ago and then never used it in the one place it mattered.

Check what your tests write to. Most people have never looked.

[Tom · SŌGŌ @0xtomdev]

that clears it up ty.

sub 400ms detection is solid, the closures thing is the part that stings tho, cause open only means the sample skews toward positions that survived.

anything that opened and closed fast is invisible by construction, not by policy.

if X flags closures as spam theres a way around it, batch them into a periodic roll up instead of one post per close. same data, one post....

[Tom · SŌGŌ @0xtomdev]

spent three hours today deleting code i wrote last week.

it worked fine. it just made the money path one layer harder to reason about.

better slow than wrong isnt a saying for me, its a merge rule

the version that ships is always the boring one

[Tom · SŌGŌ @0xtomdev]

Two properties fell out of that which I did not plan for.

It is redeploy proof, because there is nothing to lose.

And it is venue agnostic, because the check never touches venue state.

Rotating the secret also became a control plane kill switch that works with no volume flowing.

https://t.co/9vpyfo7422

[Tom · SŌGŌ @0xtomdev]

My fill watcher used to halt trading because of a redeploy.

Every order got a client order id. The watcher journaled that id to disk. When a fill came back, it checked the fill against the journal to decide if the order was ours.

Ephemeral disk. Redeploy wipes the journal.

Now every order in flight is an order the watcher has never seen, and the safe reaction to an unrecognised order on your own account is to stop.

[Tom · SŌGŌ @0xtomdev]

Fix was to stop storing and start signing.

The client order id is now derived with an HMAC over a secret only the service holds.

Verification became a recomputation instead of a lookup. Is this id one we could have produced. Yes or no.

[Tom · SŌGŌ @0xtomdev]

tiering these by expected drop is one axis but the S tier separator is usually just points per unit of taker volume and whether that ratio is fixed.

half this list rebalances it the moment scripted flow shows up, other half never published one at all.

wwhich of these actually document theirs?

[Tom · SŌGŌ @0xtomdev]

the turn it off part is where that breaks.

resting orders dont die with the process.

weve had brackets still sitting on the book after a redeploy with nothing left to reconcile them against. kill it mid inventory and ur holding a position with live orders and nothing managing either

[Tom · SŌGŌ @0xtomdev]

@givenoxbt @variational_io fair. the thing that decides it after that is whether the ratio stays fixed once scripted flow shows up.

usually gets rebalanced the moment it does, cause the venue is optimising for fee revenue not for points distributed

[Tom · SŌGŌ @0xtomdev]

@Capy_Research ye thats the gap. every venue reports on a different base, some net the deployer cut some dont.

weve been pulling it per venue by hand and our own event log still drifts from the venue sum by a small constant. if a normalised series exists somewhere wed take it

[Tom · SŌGŌ @0xtomdev]

@mogie__ heard that today twice

[SOGO Terminal @sogoterminal]

SOGO ship-log — 31 Jul 2026
volume routed: $17.4K
builder fees: $8.70
cumulative: $100.99
traders: 1
next C1 $100/day — 9%
live + on-chain: https://t.co/efSHLRhRMH
non-custodial HL terminal in Telegram · 2.5bp direct · 10bp crew lane (leaders earn a share of fees) · keys stay yours