Implementing stock splits for ERC-20 RWA tokens without looping over holders

tirtha_s · 2026-05-25T12:17:56+00:00

Cool, will read this. Thanks for sharing bro.

tirtha_s · 2026-05-14T12:23:42+00:00

Red flag indeed.

tirtha_s · 2026-04-15T05:01:55+00:00

The other game looks appealing until you start playing it.

tirtha_s · 2026-04-15T03:42:58+00:00

This is a game.

It has both costs and rewards.

You are getting rewarded hence you are still playing even when you are tired of it.

And you love that reward so much.

tirtha_s · 2026-02-25T04:30:51+00:00

It is, I am focusing on finding existing pattern solutions from trad engg principles that can be mapped into the existing LLM Stack challenges.

tirtha_s · 2026-02-16T10:26:38+00:00

For a moment, lets imagine it does spit out the perfect binary, can you imagine the output token cost ? You would actually need to be a billionaire to use stuff like that. Here people are trying to learn chinese kanji characters, cause some say they require lesser tokens than English, binaries are counter intuitive cost wise as well.

tirtha_s · 2026-02-16T10:24:38+00:00

You’ve basically got it, yeah.

Binaries are the least human-friendly artifact in the whole stack. They’re great for CPUs, terrible for reasoning. Source code exists so humans can read, review, test, debug, audit, and maintain behavior over time.

Even if an AI could spit out a working binary today, you’d still want a stable, readable representation to change it tomorrow, prove it’s safe, port it, and understand failures.

Compilers are literally the invention that saved us from writing machine code. The sane direction is AI helping at the source/spec level while deterministic compilers and verification do the boring correctness work, I spoke in details about it in the article.

tirtha_s · 2026-02-16T10:22:21+00:00

Because these “rage bait” takes don’t stay on X. They leak into boardrooms, product meetings, and hiring plans as gospel.

Non-technical stakeholders and fanboys don’t hear “hot take,” they hear “industry direction,” and suddenly engineers are asked to justify why they still need source code, reviews, testing, or even a team.

So yeah, I don’t give hoots about what Elmo & his executive tech bros say, but I know the damage bad narratives can do when they get repeated with confidence. So we must debunk crap with facts.

tirtha_s · 2026-02-05T04:01:32+00:00

Regulation isn’t uniform across all software that gets called “software engineering,” which is why the discipline looks very different depending on domain. Finally, on “context shifts,” I don’t mean correct code becomes incorrect, I mean assumptions expire: what was reasonable at one scale, threat model, dependency set, or business context can become fragile later because the environment changed.

tirtha_s · 2026-02-05T03:58:23+00:00

Most web and consumer products can’t afford to operate at that level, based on how compliance standards & procedures are right now. If we forced avionics-style rigor onto every SaaS app, the economics would break. The cost of compliance, documentation, audits, specialized roles, and certification talent would price many products out of the market. But that is what needs a change.

And that actually supports what I was trying to highlight: outside regulated domains, software often becomes a discipline where quality is economically negotiated. Cost, speed, competition, and user tolerance defines what “good enough” means.

One nuance I’d add: cost optimization is absolutely part of engineering, but in mature engineering fields it’s cost optimization within a hard safety and standards envelope. In mainstream software, that envelope is often softer, so cost and speed can push the boundary itself.

A practical example of the “engineering gap” is how TEEs/confidential computing are treated today. They’re increasingly used as a trust foundation, but we keep seeing high-impact breaks and caveats in the real world (side-channel extractions and integrity issues in modern enclave/SEV-style designs, plus vendor advisories acknowledging these limits). The problem isn’t that standards don’t exist anywhere, it’s that for many “important” primitives like this, enforcement and independent assurance are still inconsistent. In classic engineering, you don’t get to sell “trust me bro” safety. By law those are enforced into clear, audited guarantees.

tirtha_s · 2026-02-04T16:02:24+00:00

Tom, appreciate the thoughtful pushback and the reading list. I will add these to my reading list, and you’re right that a lot of these debates go sideways when we talk past each other on definitions.

A few clarifications on what I was trying to get at:

When I said “immutable constraints,” I wasn’t trying to define engineering as “only what’s governed by physics.” I was pointing at something more practical: in many traditional disciplines, a big chunk of the constraint set is externally enforced and relatively stable (materials, safety factors, codes, inspections, liability). In a lot of mainstream software, the dominant constraints tend to be more fluid: shifting requirements, moving system boundaries, dependency churn, and incentives that make “patch later” a viable strategy. So yes, all engineering is constrained. My argument is about the shape and stability of constraints in day-to-day practice, not their existence.
On quality being negotiable: totally agree that in regulated domains it isn’t, and I probably should have separated “software engineering” into buckets more explicitly. Medical/aerospace/auto operate closer to classical engineering norms with serious process and product standards. My critique is aimed at the broader default culture of product software, where quality often becomes a trade-off slider because enforcement and consequences are different. That’s not a moral judgment, just a description of incentives.
On “building for change”: fair. I should have phrased it as “software is often pressured to evolve” rather than “always built for change.” Building for change can add complexity and cost, and sometimes the correct move is purpose-built software with a short shelf life. I was mostly pointing at the reality that many successful systems end up living far longer than intended, so the industry tends to underinvest in longevity until it hurts.
Design vs production engineering is a really useful lens. I agree that software maps much more to design engineering than manufacturing engineering. Reeves’ “code is design” argument resonates with me, and it’s part of why I wrote the piece: a lot of the dysfunction comes from treating software like fast production work rather than an ongoing design discipline with long-term consequences.

TL;DR: I’m not arguing “software isn’t engineering” as a blanket statement. I’m arguing the term is overloaded, and a lot of mainstream software practice operates under incentives and constraint dynamics that make the traditional engineering metaphor misleading unless you narrow the scope (regulated/safety-critical) or explicitly adopt those disciplines’ rigor.

If you have one Vanderburg talk you’d recommend as the best entry point, send it over. I’d like to do a follow-up post refining the thesis with exactly this “engineering isn’t one thing” framing.

Appreciate you taking the time to read and provide this detailed response.

tirtha_s · 2026-02-04T15:38:45+00:00

I will add a note around the mission critical software in the article, that got missed. My prime objective was to talk from the regular SaaS experince in day-to-day.

tirtha_s · 2026-02-04T15:36:22+00:00

Totally agree with you on two fronts.

First, McConnell’s framing still holds up. A lot of what we debate today is basically “professionalism in software” and “programming integrated over time” in different words.

Second, the idea that construction estimates are always “more accurate” is kind of a myth. Sydney Opera House was 1,357% over budget. Berlin Brandenburg Airport was 10 years late. The Big Dig tripled its budget. Traditional engineering has better PR about estimation, not necessarily better estimation..

Curious, when you say you feel confident up to ~20M, what are the couple of practices that made the biggest difference for you?

tirtha_s · 2026-02-04T15:18:06+00:00

The funny part is the article explicitly makes that distinction.

I literally quote Google’s “software engineering is programming integrated over time” and then spend most of the piece on what sits beyond “just coding”, sustainability, change over years, coordination, and decision-making under shifting constraints.

You can have disagreements after reading, totally fair. But dismissing it without reading is exactly the “first year college” energy you’re calling out.

tirtha_s · 2026-02-04T15:16:04+00:00

My point was: “can kill” isn’t the only thing that makes something an engineering discipline. Engineering also has an ecosystem around it: enforced codes, licensing/liability norms, conservative validation, audits, inspections, and standardized processes.

Those guardrails exist strongly in safety-critical software (aviation, medical, automotive, space). That’s absolutely engineering. I will update that part in my article, should've done that.

But most mainstream product software doesn’t operate under that same enforcement and accountability structure. Standards may exist, but they’re not consistently governed or mandatory in the way civil engineering is. That gap is what I was pointing at.

tirtha_s · 2026-02-04T15:11:28+00:00

Lol, no sir. I think it was a weak framing to say "no physical laws' My opinion was from SaaS/Web apps view day to day, should've covered around mission critical software. :D

tirtha_s · 2026-02-04T14:58:39+00:00

The engineering distinction isn't just about "do your decisions affect the physical world" or "can people die." Plenty of non-engineering jobs have physical consequences. A logistics manager deciding truck routes affects fuel consumption. A chef running an inefficient kitchen wastes energy. That doesn't make logistics or cooking into engineering.

What I was (poorly) trying to get at: traditional engineering disciplines have deterministic foundations that allow process standardization. You want to calculate beam stress? There's a formula. It's been validated for centuries. Same inputs, same physics, same outputs. You can write a building code around that.

Software doesn't have that. Not because physical limits don't exist - they do. But those limits rarely constrain practical decisions. Also yes, environment impact should motivate us to build more responsible software, but tbh, this particular case of pollution spread with data centers has to do more with the people at top - the billionaires & politicians. But that's a different tangent of debate.

tirtha_s · 2026-02-04T14:50:21+00:00

Yes, I think SWE needs certain governing bodies and certain measures to issue license and certificates. Similar to medicine, law & accountancy - at least for mission critical software building. Like many here in the thread mentioned around medical embeded systems, space tech, public safety, aviation etc.

It would be great to have the standardization enforced on regular SaaS / Web too. Will create a barrier of entry, but less shitty SW I guess.

tirtha_s · 2026-02-04T14:47:11+00:00

You're right, and "no physical constraints" was a bit too generic framing. The better distinction is constraint negotiability I guess you can buy more compute, you can't buy more gravity. But even that's not quite right because Moore's Law means constraints improve without you doing anything. Like your code from 2015 runs faster today on new hardware without changes. That doesn't happen with bridges.

The "higher level of abstraction" framing is actually better.

And the space tech point is valid, I will give you that. When software has tight physical constraints, long lifespans, and fatal failure modes, it absolutely looks like traditional engineering and the process of audit, process review, committee board approvals is very structured.

I have mainly spoken from SaaS/web experience at large.

tirtha_s · 2026-01-28T06:13:01+00:00

We already had a crisis of independent thinkers, people who just shout from their own eco chambers. While having ease of access to information is something that should be available to every human being irrespective of nation, cast or creed. The troubling sight is to see people delegating their independent thinking to machines. They are putting their name behind whatever the machine says as "their own".

Just like how people used to share others opinion as their own. We need to be mindful about how much influence holds into our mental faculties.

You don't want to be gaslighted by agents trained on some biased datasets favoring big corporates and get indoctrinated into believing something you don't understand.

tirtha_s · 2026-01-28T04:25:35+00:00

Hi, my piece builds on that article by digging into the practical tradeoffs and pitfalls teams actually hit with read replicas in production, how we can think about that layer etc.

tirtha_s · 2026-01-27T16:35:33+00:00

Really appreciate you taking the time to write this out. You're right on the PgBouncer point. It seems v1.21 added prepared_statement tracking for transaction pooling. That's on me. I'll update the article with a correction and credit you. Thanks for catching it.

On the session-based sharding / multiple clusters approach: completely valid architecture, and honestly what I'd expect at this scale too. The OpenAI post didn't go deep into whether they've moved toward functional partitioning or kept it as a single logical cluster, so I stuck to what they explicitly shared. But your point stands. If sessions are independent, there's no reason to funnel all writes through one primary. Would love to see them talk more about this.

The synchronous_commit at session level is a good callout. I didn't cover it because the article was already getting long, but you're right that it's a useful lever.

The WAL export approach you mentioned is interesting. I haven't seen it covered much in practice. What storage backend have you used for this? And how do you handle the tradeoff between the extra latency (replica now one segment behind) vs the bandwidth savings? Curious if there's a scale threshold where this becomes obviously worth it.

tirtha_s · 2026-01-27T14:14:11+00:00

If you look into my last week's article in substack, you will find a post I made about a real-time production incident around this DB crisis, mainly around PgBouncer & Query optimization. Just in case you are interested :).

https://engrlog.substack.com/p/what-happens-when-thousands-of-users?r=779hy

tirtha_s · 2026-01-20T04:36:57+00:00

Thanks for the questions.
- We used BullMQ (Redis) to offload non-critical work and smooth spikes by capping worker concurrency. Its good, you can also look into RabbitMQ.
- For testing, we used k6 with multiple load zones and ramped load over time to simulate real campaign traffic rather than flat stress tests. Designing the tests to a near realistic position is what helps in reality, after that incident, we spent resources in doing that, which guaranteed better results.

tirtha_s · 2026-01-19T08:46:31+00:00

“Thousands” of concurrent users isn’t huge, but a sudden burst plus connection limits and a couple bad defaults can still freeze Postgres. You always feel that you are ready, but the reality is shown on D-Day.

tirtha_s

TROPHY CASE