Our years of background in crypto data informed the design of Trails Bottom up, from contract primitives (functions, events, constants, etc) to our Explorer (search, understand) to Trails (app layer)

The more time I spend working with coding agents, the more convinced I am that they make software engineering even harder We can do amazing things with them, but unlocking their full potential requires extraordinary discipline and knowledge

JavaScript was never designed for the server. If that doesn't change soon, JavaScript on the server will be replaced by Rust. The fix needs to happen in the engine. Sound types. Ahead-of-time compilation. Threads with shared objects.

Herd is covering the Monad ecosystem! The Herd team is doing a nice job of automatically disentangling chained dependencies across DeFi. I believe that with better information, we can all make better decisions. Now on Monad

a big blackpill moment for me was when I saw the senior staff eng that used to block my prs for poorly named functions start to directly merge claude outputs into master

We've fully integrated a new chain for the first time since launch: Monad has now joined the Herd! This means full support across our explorer, onchain actions (hal), and doubleclick graphs - both in app and over mcp/cli/sdk!

make it write good typescript and i’ll be impressed

Did anyone actually read the SEC Exemptive Relief letter for Tokenized Securities? I read the 60 pages today, and the carveout is incredibly limited. Considering the celebrations on X, I thought it would contain something useful, but imo there isn't demand for the model proposed / nor is any incumbant already meeting the requirements as written. I haven't seen anyone properly breakdown what it actually says, so here are the most important parts with my commentary: 1. Permissioned Participants Only. Tokenized Security Venues (TSVs) can "facilitate the permissioned trading of tokenized NMS stock using innovative automated market makers." The key word is "permissioned." It's mentioned multiple times throughout the letter. Permissioned means whitelists, whereby both the LPs and traders are known, KYC'ed and KYB'ed. Onchain stock AMM liquidity/execution is already terrible, and that's without limiting to permissioned entities. Who is actually going to provide liquidity into these permissioned venues? It's not market makers. Market makers prefer CLOBs because they are more capitally efficient. Market makers also prefer bilateral trading via single dealer platforms (or as the cryptonatives call them propAMMs). There is limited supply side liquidity for permissioned AMMs. It's either permisionless AMMs or permissioned structures other than AMMs. 2. What is a Tokenized Security Venues (TSV)? A TSV "brings together buyers and sellers of Tokenized NMS Stock by: (1) providing one or more AMM Liquidity Pool(s) for permissioned participants to interact and agree to terms of a trade and (2) setting standards for persons to access trading on such AMM Liquidity." By this definition, Hyperliquid's CLOB model would not count for exemptive relief. Hyperliquid Spot (not perps) does ~50% the daily volume of Uniswap. But, to put things in perspective, Hyperliquid only has 70 spot pairs(!!). It's obvious, there will be tighter execution and better discovery on CLOB models like that of Hyperliquid. We need permissioned CLOB or propAMM structures included in the definition. In fact, as I'll get to below, the SEC even calls out the fact that AMMs lack best execution protections... whcih could easily be implemeted in CLOB structures! 3. What counts as a Tokenized NMS Stock? First, a Tokenized NMS Stock must be registered with the SEC. Second, a Tokenized NMS Stock "does not include securities where a third party issues a crypto asset representing its own security that provides synthetic exposure to an underlying security, such as a tokenized linked security or a tokenized security-based swap." To be clear, none of the permissionless representations of stocks today are SEC-registered securities @RobinhoodCrypto @coinbase @binance @Ondo @xStocksFi etc. The fact that they are not, means nothing in this letter pertains to them. To be clear, it does NOT mean that these models are inferior (in fact I would argue the opposite, but that's outside this scope.) Lastly, a Tokenized NMS Stock can only trade against "another Tokenized NMS Stock, a non-security crypto asset (e.g., a payment stablecoin issued by a permitted payment stablecoin issuer), or a tokenized money market fund." The phrasing is vague here to me, does "non-security crypto asset" include memecoins??? 4. Lack of Consumer Protections and Risks with AMMs In the US, investors are given best execution protections. Without these protections, market makers can provider inferior execution and manipulate spreads at investors expense. These protections are part of Reg NMS. Alarmingly, the SEC says consumers will NOT have these protections in TSVs: "A TSV could not comply with the requirements of Regulation NMS without significant modifications to its trading model, which may adversely impact TSV Participants." Why are we going down the AMM path? Without these protections, who is going to participate on the demand side? As mentioned above, we have severely limited the supply side, now we are effectively saying to consumers, "Spreads will be wide, good luck." You know what can easily abide by Reg NMS? CLOBs like that of Hyperliquid. With both supply and demand sides hamstrung, we're setting ourselves up for failure. But on a positive note.... 5. The SEC recognizes the benefits of Blockchains! TSVs "offer the potential to benefit investors by enabling investor self-custody, around-the-clock trading, fractional ownership of shares, and near instantaneous settlement.... The use of such technology may also lower operating, recordkeeping, and transaction costs, and improve efficiencies." 6. Long list of Requirements to become a TSV Pages 36-46 are a long list of requirements TSVs must make publicly, including things like, "a TSV must consent to examinations of its books and records by the Commission staff at any time" and "at least 30 calendar days before operating, a TSV must publish a copy of a notice (“Notice”) prominently on its publicly available website." 7. Issuer Protections, Remember AMC / Robinhood?! We all remember the AMC debacle. The SEC is giving AMC exactly what they asked for: required issuer permission for the tokenized security to exist. "If [AMC] provides... written notice to the TSV that it objects to a Tokenized NMS Stock... the TSV cannot make such Tokenized NMS Stock available for trading on the TSV." This line reads almost directly from the AMC incident: "An issuer of the underlying NMS stock may be concerned about the risk of maintaining its shareholder register related to onchain transfers or the potential price dislocation or adverse effects on the price of the underlying NMS stock, particularly given that prices disseminated by an AMM Liquidity Pool are most likely based only on the ratio of the quantities of assets in that liquidity pool." Yet another reason to prefer CLOBs where the prices are not directly linked to a single pool which could be mispriced. 8. Tokenized Stocks must have the Same Benefits Tokenized stocks must have "a right to receive the same dividends... a right to exercise the same voting rights... and a right to receive the same share of the residual assets of the company upon liquidation." Great stuff! Investors in tokenized representations should get everything (and more!) than they would in the traditional form. 9. Extremely High Volume Limits and Other Controls The limits the SEC has set for volume are sky high. The "volume of Tokenized NMS Stock Traded... cannot exceed 0.25 percent of the average daily share volume during the prior month in the relevant NMS stock as reported by an effective transaction reporting plan". The TSV must pause trading" For reference, even the permissionless versions of these tokenized equities are doing less than 0.001% of the volume. Remember today, there are only $3 bn in tokenized equities. The market is $70 trillion. ---------------------------------------------------- Expect a formal comment letter submitted to the @SECGov from myself and @glider__ soon.

love brian but ATPs are not an apples-to-apples comparison to vaults. while its good rage bait, it is just making everyone more confused everything in defi comes down to "strategy" and "custody". a strategy is a managed set of allocations across contracts, and custody sits both above and below the strategy (how do you "hold" a position in the strategy, and how does the strategy "hold" positions across other contracts). The primary ATP strategy today (an ETF) is safer than a variety of strategies run by vaults. My mental comparison of glider today is against my metamask or coinbase account, not against some steakhouse vault. When glider gets to openly creating and managing strategies that ATPs can allocated into, then we are getting closer to an apples comparison. I believe the complexity of contracts/oracles is unavoidable, you can abstract it with an API sure but it is still there and institutions will still want to audit down through every layer (they aren't going to just sign off on your api). It's not a problem you can just run away from. I also know I tweet large token graphs often, but more contracts != more risk always. For example, centrifuge has like 30+ contracts just to manage bridging of an asset because they want fallbacks/gates/agreement across different bridges (chainlink, layerzero, and axelar). And if you want to allow different strategies, you have to segment what operations are allowed by what operators (this is the bulk of contracts for any protocol/vault). Privy wallets give glider full authorization to do anything they want on behalf of the user, but eventually that will have to become more segmented like a policied weiroll solution which a few other teams are close to launching (like makinax). I'm seeing enough confusion on the timeline that it's probably worth me writing an article about the layers of strategy, custody, and operations in defi today.

Just got called unc for reading the code, let's go

The "whiteboard defense:" I should be able to pull you aside at any moment and ask you to explain any customer-facing system you've shipped. You should be able to clearly explain how it works and defend the decisions you made. This is my benchmark for responsible AI usage. I don't expect line-level familiarity with the code. I don't care if you remember the exact function name or implementation detail. You may not even know it. I don't care. But if I ask "why did you do X instead of Y?", "what happens if this actor behaves maliciously?", "what data structure did you use here and why?", or "where does this fail?" you should be able to answer confidently. For PoCs, demos, experiments, whatever: I don't care. Generate 100% of it and understand none of it. Speed over quality every time in those specific scenarios. But if you're shipping customer-facing work, you can't be shipping things you don't understand at a high level.

pov: you're about to receive ultraslop

Languages don’t matter because AI writes them is the same argument as languages don’t matter because my team writes them and not me. It’s dumb, languages matter even more because AI produces more code than humans

🎯 The @herd_eco engineering team made a tactical bet on the syntax barrier being broken down as models got better and it paid off 🫡

me too 🫡 Excited to connect with fellow builders, customers and friends in SF this October 🙂

Yep another banger from @rivet_dev

people say, “Oh, data analytics is already solved, just give it up,” but even with the most powerful models, we can see that it is still not 100% solved. I think it is also highly dependent on who is actually in the driver’s seat. @andrewhong5297 and Herd.eco are a good example of that domain expertise. I will not name names, but there are multiple slop platforms where, even without considering how awful the UI is, the data itself is maybe 80% correct while the remaining 20% is still missing. that gap exists because they do not have the right domain expertise to steer the AI toward what is missing, or they do not even know that the gap exists.

building good agents is hard.

if you're building an agent or a harness, you need to be an order of magnitude closer to the code than you would be normally models are VERY bad at building harnesses & agents - not sure if it's lack of training data or smth else but they have exceptionally bad intuitions about context management and the agent loop and caching and a lot of other components that matter a LOT it is very high-leverage to design the code yourself - if not typing it by hand, still do the program design yourself