cds-amal

I went through @solanaturbine Builders program on purpose, with a background in blockchain and developer tooling already behind me. Not to relearn the basics. To feel the gaps a newcomer feels, from the inside. A thread on what I found, and why I'm grateful for it. 🧵

Thanks for the explanation. Payment automation is sorely needed. Congrats on the milestone! One question on the use of "composable": it sounds like you're using it in the additive sense (can interact with any Solana program). Does the policy model also support constraints or negative composition? For example, can a policy express things like: "interact with any program except these addresses," "never send funds to these wallets," or "only interact with contracts on an allowlist"? In other words, is composability purely about expanding what a policy can do, or can it also restrict what it won't do?

glad you asked. In Tributary we have 2 sorts of policies: - PaymentPolicies: they take care of payments only. Think, subscriptions where your authorize the program to move funds to a service provider on a regular basis. E.g. 40$ -> netflix every month. That's for payments, easy, boring - ComposablePolicies: Similar in that the user specifies how much and how often funds leave your wallet, but then it comes with validation and routes it into another defi primitive. Think: buy 50$ worth of $ANSEM every monday morning 3am. "Composability" in our contest means that we can pull funds out of your wallet (as per your approval) and put it into **ANY** smart contract on Solana. You can swap via Meteora, Raydium, you can gamble, play dice games, you can increase collateral when you leverage nears liquidation - all automated with clear rules of when, how much and how.

First time today i got a composable policy installed on devnet. We are so close to complete the prototype..

After days immersed in generator design, I suspect every mature ecosystem converges on the same architecture. Lookup for known names. Scope for introduced names. Enforcement. It wasn't invented. It’s the shape of the job.

Every code generator has two namespace problems: • resolving names that already exist • introducing names that don't collide Separate those and proc-macro design clicks. open.substack.com/pub/cdsamal/p/…

Use npm v12 to mitigate some of the supply chain attacks! this should be read by anyone who runs any npm related software

@joshyote A small amount of capital, a bottle of anything, a large amount of luck, and one bug with the common decency to betray the bureaucracy that created it.

What do you need to reach the next checkpoint for your project? More users, feedback, capital, distribution, talent, marketing, claude credits? Let’s see who can help

12/ Live on devnet now. App: vesting-position.vercel.app Docs: github.com/Canguilhem/Ves… If you're launching a token and need vesting infrastructure, let's talk. Repost if you know a project that needs this. @rajgokal @SOLBigBrain

That's why the Zen has stuck with me for so many years. It's not a checklist @DiscRisknBisque It's a collection of reminders that good software is often less about cleverness than about reducing unnecessary ambiguity.

That's a tiny design choice, but it's representative of a larger principle. Software lives longer than we expect. Every bit of context you make explicit is one less thing a client, reviewer, or maintainer has to infer.

One of my favorite software Easter eggs, @dipesh_sukhani: python -c "import this" It prints The Zen of Python by Tim Peters. I've come back to it surprisingly often over the years. Not because it's scripture, but because it's a concise collection of engineering tradeoffs.

This is sick dev-tooling, can't wait to dive in.

Software history is a pursuit of increasingly complicated questions: Does it compile? Does it run? Does it work? Does it work on my machine? their machine? Does it still work? Why doesn't it work? Why does it work? The final question is traditionally the most expensive. The answer is rarely 42. But a well-written test often gets surprisingly close.

Here's an example testing the thesis on the recently released subscriptions program (@dev_jodee ) It would be nice to have examples, that shows how to use the the program. I used the "vocabulary" derived from the codama-idl to write scenario tests, and the book is generated from the test results. @micaiah_txtx cds-rs.github.io/sol-babelfish/…

Exactly in principle. The interesting part isn't just the prose; it's that the tests assemble a higher-level vocabulary on top of the IDL. @lorismatic @solanaturbine @japarjam @ludo_txtx An IDL states what instructions exist and their signatures. Narrative tests express concepts like "open a position", "deposit collateral", "claim rewards", or "liquidate" as verified stories composed from those instructions. That gives both humans and agents an API boundary that's much closer to the protocol's intent than the raw instruction surface. The resulting semantic layer becomes the protocol's DSL: a vocabulary for expressing user journeys, implementation specifications, expected outcomes, documenting exploits, and asking system-analysis questions. That's important because on-chain protocols (potential monsters) have unusually long lifetimes. Years from now they'll be integrated by teams that didn't write them and analyzed by agents and attackers with tools far better than we have today. A durable, executable vocabulary for describing and validating behavior isn't just documentation; it's institutional knowledge that compounds over time.

Hey @xer0c, here's a concrete example of what I have in mind: codama-idl + .so = cds-rs.github.io/sol-babelfish/… I see this as something protocol developers narrate real-world use cases with runtime-verified claims. Documentation and tests become the same artifact. For on-chain protocols, that's especially compelling. These systems can live for years, accumulating new integrators and facing increasingly capable attackers. Keeping the behavioral narrative coupled to executable tests helps that documentation stay honest as the protocol evolves. @solanaturbine @solana_devs @ludo_txtx @lorismatic

Quick question about Surfpool's forking model. One of the things I really liked about @trufflesuite Ganache was that it could fork Ethereum mainnet at arbitrary historical blocks because it had archival access through @infura_io's support. Does @surfpool_sol have that kind of support from @solana, or do we have to bring our own RPC provider? My use case is protocol archaeology: I'd like to fork the chain immediately before a historical transaction, replay it locally, and experiment with alternative execution paths. @ludo_txtx

That's a really interesting comparison, and I think they occupy adjacent parts of the design space. qedgen starts from an explicit specification that the protocol author writes, then generates different verification and testing artifacts from it. The spec is the source of truth. What I'm exploring starts from the opposite end: what if the only things you have are the deployed .so and its IDL? That's the reality for an integrator consuming someone else's protocol. The generated Rust isn't the specification; it's the vocabulary. It lets you describe scenarios in the protocol's own language, execute them against the real program, and produce a narrative of what happened. Happy paths, failure paths, state transitions, authority changes, all as executable documentation. IMHO the approaches are complementary. One specifies what a protocol should do. The other helps downstream builders understand and communicate what a deployed protocol does. And that's important because on-chain protocols have unusually long lifetimes. They'll still be running years from now, being integrated by teams that didn't write them and probed by attackers with better tools than we have today. Having a durable, executable vocabulary for discussing and validating behavior becomes an asset that appreciates over time.

This is really cool. Bear with me, what's the difference to using qedgen where you put your "state maschine's transitions" into a qedspec file and use that to generate proptests, lean tests or kani tests. Both produce a "specification" of what the behavior should look like. Your's (arguably cooler) by using the IDL and the .so.

I generated 5k lines of Rust over the last week. Plot twist: no AI wrote it. No macros either. A code generator read one JSON file, a file every deployed Solana program already ships and typed out an entire test surface. Like the old days, using bison, lex and yacc. Thread on testing programs you have no source for. 🧵