Lab Notes 05
TL;DR:
First YaaS deployment is live with @orogoldapp driving +22.05% LP APY, 3.5x growth in pool, and CoinDesk Research featuring our YaaS partnership with Oro in their recent stablecoin research piece.
Upcoming governance proposal: (i) deploy a meaningful portion of Solomon treasury assets into deep USDv/USDC liquidity with proper oversight via a subcommittee, (ii) buy $SOLO in the open market to build up a $SOLO treasury and allow token holder alignment
Cantina audit completed. 300+ commits across 8 repos hardening the backend.
Legal/compliance hurdles are cleared, ~1 month away from completion.
Rebrand, integrations for YaaS, open access, and a major Solana related announcement incoming.
Building in public with a live token is a constant tradeoff. I want to share progress, but I can’t narrate everything in real time, especially legal and compliance. Some details get used against you, whether that’s competitors, counterparties, or people trading around timelines.
Here’s one early decision that shaped how we’ve been moving.
When we started talking seriously about launching on MetaDAO, it was right around October 10th. We got through that dislocation with zero issues, which gave us confidence in the core system. But it also changed the rollout environment. Our yield comes from the basis trade, so funding matters. Post 10/10, funding collapsed and stayed weak.
That flipped the risk-reward. Scaling retail at that moment would’ve meant manufacturing demand with incentives and TVL deals, and doing it on top of legal/compliance and infrastructure that weren’t where we wanted them yet. It probably would’ve looked good short term, but it would’ve anchored us to mercenary capital, token reflexivity, and a foundation we’d eventually have to unwind. We chose the durable path instead. Invest in legal/compliance and build the infrastructure we actually want to scale on.
And the sequencing flipped too. We thought it would be “retail first, then YaaS.” In reality, the pull for YaaS showed up earlier, and from serious places. Since this is partnership dependent, legal/compliance quickly became the hard bottleneck.
Fast forward to today: for the first time, we have real clarity on the legal/compliance path. I’ll get into that later. First, here’s what we shipped over the last month.
YaaS v1 Went Live (Oro × USDv)
Last month we shipped the first production instance of YaaS.
https://x.com/orogoldapp/status/2016574665284612227
We partnered with Oro to move a portion of their main liquidity over to USDv and stand up the GOLD–USDv pool. The core is rooted in a simple idea: the stable leg inside an LP position should be able to earn, without wrappers or vault interactions, so there’s no extra smart contract risk just to access yield.
Early stats (first 23 days, annualized):
LP fees: 16.23% APY
LP fees + YaaS rewards: 22.06% APY
Net uplift from YaaS over that window: +5.83% APY
LP Volume Cumulative: $1,257,989
During this period we worked closely with the Oro team on fee tuning and modeling. The thesis is straightforward. If YaaS is adding a baseline return to the USDv inventory inside the LP, we can price the GOLD–USDv pool slightly cheaper than competing pools and win more flow, which can translate into more fee capture per unit of liquidity.
That dynamic showed up in the data. In lower-volume periods, the GOLD–USDv pool captured a larger share of flow and generated stronger fee yield (excluding the added YaaS rewards from the opt-in). In higher volume, GOLD–USDC still produced higher fees, largely because it has deeper liquidity today. We’ll get a cleaner read once pool sizes are closer to parity
Given the results and the additional yield, Oro has steadily increased the size of the GOLD–USDv pool from ~$100k to ~$350k. It’s still constrained by our current cap, and we expect it to scale materially once we’re able to open more cap space.
We also saw demand from users who wanted to add positions specifically to access YaaS. We’re still gated, but open access is coming soon.
We expected to ship two more YaaS integrations last month, but partner timelines slipped. Both are still in motion and should land shortly.
CoinDesk Research took notice of the YaaS role out and covered it here:
https://x.com/CoinDesk/status/2023819782542553391
Cantina audit completed
We also wrapped up our latest audit via Cantina who reviewed the core onchain programs behind USDv:
https://x.com/cantinaxyz/status/2017281703447040060
USDv is now routable on Jupiter
In addition to this, USDv is now treated as a stable and included in Jupiter routing. Jupiter doesn’t add an extra fee on top here, you’re just paying the underlying route costs:
https://x.com/solomon_labs/status/2019875829430546697
Backend
Commits: 300+ across 8 active repositories
This month’s engineering work was mostly about hardening and widening the foundation. Making our onchain state reconstruction engine production grade, expanding multi protocol coverage, improving observability, building governance tooling, and shipping supporting cloud and platform upgrades.
AMM state reconstruction engine
The bulk of the month (198 commits) went into hardening the AMM state reconstruction engine. The goal is simple, given raw onchain transactions, we should be able to deterministically reconstruct pool and position state with the same outputs the chain would produce.
Major milestone: our discrete bin state machine now produces results fully consistent with onchain state across all tested transaction histories. That’s the culmination of weeks of work on fee modeling, position lifecycle tracking, and bin level distribution math. Exact parity is the prerequisite for everything downstream we care about:correct fee attribution, accurate PnL, and eventually automated strategy operation.
Key progress:
Multi-protocol coverage: instruction + event processing now supports Meteora (DLMM + DAMM v2), Orca Whirlpool, Raydium (AMM, CLMM, CPMM), and MetaDAO Futarchy. This is the base surface area we need to operate across the major Solana liquidity venues without being boxed into one protocol.
Position-level PnL tracking: implemented a share-based accounting model to track profit/loss at the individual position level, including fee accrual, rebalancing events, and realized outcomes on withdrawal.
Invariant verification: built a comprehensive invariant checking framework (generic + protocol-specific) that continuously validates outputs against known mathematical properties. This acts like an automated audit layer, catching discrepancies before they propagate.
Pipeline architecture note: what’s running today is our MVP pipeline, purpose built to get YaaS operational and battle tested. In parallel, we’ve been building the next gen processing pipeline from the ground up. The new pipeline is architected for throughput. zero memcopy design, binary stream processing, and a fundamentally different data handling approach built to scale aggressively as pool count and transaction volume grow.
Observability and terminal tooling
We continued investing heavily in real time observability. a terminal based monitoring suite that gives us deep visibility into protocol operations.
This month we shipped:
new monitoring panels (pool stats, position browsing, accumulator inspection, state machine debug views)
improved terminal native charting (liquidity distribution graphs, bin-level visualizations, time series observation recording)
volume and metrics tracking integrated directly into the monitoring pipeline
application lifecycle improvements (teardown, stdin management, title bar rendering, render scheduling) for production stability
Governance infrastructure
We also started building purpose built tooling for onchain governance operations:
Proposal Builder: terminal based proposal composition with an editor, navigator, and live preview, designed for assembling multi instruction proposals for Squads execution
MetaDAO + Squads integration: complete TypeScript wrappers for MetaDAO’s Conditional Vault + Futarchy programs and Squads V4 (accounts, instructions, events, type definitions), generated via our custom IDL tooling for type safe interaction
Governance state machines: implemented state machines for Conditional Vault and Squads V4 so we can reconstruct and verify governance proposal lifecycles directly from onchain data
Monorepo and developer tooling
Continued strengthening the foundation everything builds on (31 commits):
IDL code generator enhancements (nested account hoisting, single-field struct inlining, camelCase normalization)
expanded our Rust source introspection tooling with new parser capabilities and test coverage (Humidifi)
binary transaction storage improvements (index rebuilding + seeking for efficient historical data access)
terminal UI framework improvements (title bar widget system, hot path optimizations, render scheduler refinements)
Spec and research
Forward looking work on next gen data formats and scanning performance:
transaction tape v2 design (offset-based timestamps, bitpacking, hot/cold address indexing, repeated pattern compression, canonical instruction ordering)
scanner specification with prototypes in TypeScript and Rust for a high-performance transaction scanning approach
Governance and document infrastructure
Alongside the infra work, we also shipped a bunch of governance and document tooling. Some context on why: we’ve been spending way longer on legal than we originally expected. About a month into working with a few firms, it became clear we had to build real in house ownership here. We needed to hold the full mental model across jurisdictions and counterparties, and in a lot of cases we ended up drafting first versions of docs just to get something concrete on paper and keep things moving. That’s a big lift for any startup, and it gets even more complicated when you layer on something new like the MetaDAO futarchy framework.
The reality is we can’t “just ship” our way through this. Most of the relationships that matter are between legal entities: custody, operators, banking, partners, and even certain integrations. If the structure isn’t set up correctly and the agreements don’t match what the system is supposed to do, you don’t get to proceed...
With all of that in mind, we started treating documents like an engineering surface: deterministic, versioned, and easy to verify.
The core is two pieces:
Record Schema (spec): a simple spec for organizing records as directories with stable identifiers, typed documents, and machine-readable metadata. It enforces a small set of invariants (deterministic naming, required metadata, structural baselines) so repos become lintable, renderable, and auditable. The important bit is byte-stable adopted text surfaces, so governance documents can be hashable and reproducible.
Record Schema Toolkit (implementation): a zero-dependency Node.js CLI/API that operationalizes the spec. It discovers and validates repos, enforces formatting profiles, parses metadata blocks, computes hash surfaces, and renders docs through an AST pipeline into properly typeset PDFs.
This month we used it to ship:
Company Agreement: finalized and rendered as a professionally typeset PDF, generated from source through the toolkit pipeline (reproducible, version-controlled).
SOP registry: structured under the schema with metadata and validation in place.
DAO proposals registry: clean lifecycle hygiene (draft → vote → passed → executed), canonical pinning on adoption, immutable adopted text surfaces, append-only logs, and machine-verifiable metadata.
All of these repos are now lintable, validatable, and renderable through the same pipeline, which makes governance a lot less hand wavy.
If MetaDAO cohort DAOs are interested, we’ll make Record Schema + the toolkit available under an exclusive license at no cost. Most DAOs are still running governance off ad-hoc document piles that can’t be audited, and this is a practical way to level that up without everyone reinventing it.
Brand refresh
If you’ve been paying attention to our content lately, you’ve already seen the new brand starting to take shape. We’ve completed the branding system phase and are actively rolling it out.
Next up is the revamped landing page, which ships soon. In parallel, we’re refactoring the dApp to fully adopt the new brand system. This will ship once ready
The refresh isn’t cosmetic for the sake of it. The new brand gives us higher design quality, more flexibility in how we produce and scale content, and a cleaner UX/UI that better reflects what Solomon actually is.
Site performance
The performance work is done. We’re now focused on integration improvements to the Swap component and Wallet Connect before releasing.
When it lands, the app will load materially faster. External calls on page load drop from roughly 20 down to 4, unnecessary code and assets loaded on init have been stripped out, and the swapping and wallet connection flows will be cleaner end to end.
A few other things in motion
We’ve engaged third-party proof-of-reserve / attestation firms to add another layer of transparency around collateral backing. Expect this to come online in the next month.
We’re working with Blockworks to be one of the first teams participating in their token transparency framework.
What comes next
For the first time in a while, I feel comfortable laying out a real timeline.
We have a clear path on the legal/compliance side, and counsel is giving us roughly a month to close out the remaining items. That doesn’t mean we’re waiting a month to do anything. It means we finally know what “done” looks like, and we can plan around it.
The next month
1) The first proposal goes live in the coming days.
This is the proposal that starts putting the treasury to work.
The core is simple: deploy a meaningful portion of treasury assets into deep USDv/USDC liquidity, with proper oversight via a subcommittee.
When we raised, the original intent wasn’t to sit on idle cash. The plan was always to use capital to build deep liquidity so we can negotiate better terms with venues and custody providers, and so partners can actually rely on USDv at size. We already run extremely lean. Having roughly ~5m deployed into USDv/USDC liquidity gives us the depth we need to onboard serious partners.
The proposal will be executed in phases over about a week so the setup is clean and the guardrails are in place from day one.
2) The proposal will also cover SOLO treasury buildup.
SOLO started trading below “NAV” a few weeks ago as the market rolled over. I think that creates a real opportunity to improve alignment.
The proposal will include buying SOLO in the open market to build up a SOLO treasury. The intent is straightforward: if someone is short-term oriented, this is a clean chance to exit. On our side, holding SOLO at the treasury level gives us more options for how we drive growth and structure incentives over time, and it can be used for one or more of:
bringing in better aligned capital
powering incentives when we choose to turn them on
establishing MM relationships that help create a healthier secondary market
Any SOLO-related decisions will be communicated clearly, and there will be oversight. The proposal will have the specifics.
3) We’ll request a legal budget top-up.
We’ll also be requesting a one time top up from the treasury for ongoing and new legal/compliance expenses. We’ve operated on a very lean budget so far and used most of the buffer for audits and the current legal push. This is the part that unblocks the next phase, so we want it properly funded.
Near term product expectations
While that month is in motion, you should also expect:
the rebrand to fully go live
neobank integrations for YaaS to come online
a major Solana related announcement that meaningfully impacts Solomon
The next 6-8 months
Think of this as the checklist we’re executing against once the legal/compliance path is cleared and we can scale without gating everything:
public access expands, caps lifted, and the core protocol becomes broadly usable
major integrations with partners across Solana DeFi
Established company treasuries converting to USDv and leveraging YaaS
Multiple LP conversions to USDv and opting into YaaS
Neobanks coming online with YaaS usage in production
Vaults adopting USDv and sUSDv as core building blocks
This should drive meaningful growth in TVL. But the bigger point is compounding. once USDv liquidity is deep, distribution is real, and YaaS is a proven surface, each new partner gets easier than the last.
On YaaS specifically
The thing I’m most excited about is that YaaS is a generalized rail, not a USDv only feature. Over the next 6 months (and some of this may take longer), here’s what we’re pushing toward:
YaaS being adopted for yield bearing assets beyond USDv
YaaS being used by a major stablecoin issuer (billions in supply)
expanding YaaS tooling to support more novel applications of liquidity, incentives, and distribution (more on this later)
We’ve come a long way from when this was all just in our heads.
Progress feels slow at times, especially when it’s not public facing. But I have to remind myself: we’re moving at 2-3x the speed of previous similar startups, and we’re doing it while simultaneously hiring, shipping, and pushing through legal and ops. And we’re doing it at the intersection of tradfi/defi, permissioned/permissionless, inside this new paradigm of ownership coins.
Building a startup is a constant whiplash of highs and lows. It’s hard. Genuinely hard. But we chose to do the hard things because those are the only things worth doing. And if we keep executing like this, Solomon stops being a “project”, or a token, or a narrative. It becomes something much bigger: an infrastructure layer for better dollars, owned by you.
 | A guest post by
|