Solomon Lab Notes 01
Week one has been focused on foundations: formalizing the DAO’s legal and governance structure, hardening pool logic and event pipelines, and advancing the landing page and YaaS interface.
The bulk of this work lives behind the scenes: documents, state machines, parsers, and UI scaffolding, but it’s what will let Solomon scale.
Governance
We spent a significant portion of the week on the legal and governance foundation for the DAO.
We drafted a proposal that bundles:
Charter – defines what Solomon exists to do, what assets the protocol can touch, and the high-level risk and mandate boundaries.
Memorandum – sets out how the DAO is structured, where IP and infrastructure sit, and how economic flows are intended to move back to the DAO.
Operating Agreement – covers treasury operations, decision-making rules, and how protocol revenues are routed.
The intent is straightforward: SOLO is an ownership coin. Protocol, IP, infrastructure, and revenues are designed to sit under the DAO entity, and these documents are how we bind that in the off chain world.
We formalized the entire proposal process with a structured schema and documentation convention that tracks metadata, execution bundles, and governance timelines. While following it is optional for actual governance validity, it gives us clean archival, machine-readable status tracking, and a pattern other protocols can reference when building similar systems. We’re looking forward to sharing the full proposal soon.
Protocol Engineering: Pools, State Machines, and Events
On the protocol side, most of the week went into making the system behave correctly under stress and giving ourselves clearer visibility into what it’s doing onchain.
Pool State Machines
We continued iterating on the pool state machines that sit underneath USDv and YaaS:
Began modeling additional pool types / vendors to expand our integration surface.
Separating state machines from the persistence layer to make them side-effect-free and more testable.
Breaking out storage into tiered layers, in-memory and memcached for hot state, SQLite for persistent disk storage, with a tiered approach based on access patterns (hot/semi-hot/cold).
This incremental work gives us cleaner abstractions and prepares the foundation for scaling TVL securely across multiple pool types.
Internal Solana Tooling and Log Parsing
We continued refining our automatic Solana client code generator this week. The tool now optionally introspects reference TypeScript and Rust source code alongside IDLs, giving us more accurate type definitions and automatic implementations where possible.
The improvements mean:
Faster integration of new Solana programs into our client library.
More reliable generated types that match the onchain behavior.
Less manual patching after generation.
This reduces integration time for new protocols as we build out our infrastructure.
Alongside this, there were the usual rounds of refactors, safety checks, and wiring the improved event pipeline into our internal dashboards.
Front End: Landing Page and YaaS UI
On the front-end side, we’re balancing short-term clarity with a larger design refresh.
Landing Page – tightening copy and structure so new users can understand USDv and YaaS without needing a long external explainer.
YaaS UI – finishing the user flows for deposits, position views, and yield
Full Visual Refresh – in parallel, we’re doing a full brand refresh revisiting the end-to-end design (eg. colors, typography, components, illustrations, animations).
Operations, Partners, and Tooling
Beyond code and documents, a meaningful chunk of the week went into coordination with external teams.
Infrastructure and coordination tooling (including Squads)
DAO and multisig setup
Permissions and role design
Upgrade paths and day-to-day operational controls
Launch partners
Updating partners on launch plans and target dates
Security audits
Working with auditors for second round of program audits ahead of public access
What This Means and What’s Next
Most of this week’s work was about removing prerequisites to broader USDv usage.
From here, the path is:
Technical hardening: complete work on pool logic, event pipelines, and operational controls so the system behaves predictably under load, not just in ideal conditions.
Legal and governance completion: finalize the charter, memorandum, and operating agreement. Once these are in place, the DAO can begin deploying treasury assets into the strategy under the new structure (and passing of proposal).
Progressive access: move from gated beta to broader public access
Our focus is simple: move to public access as quickly as possible without compromising security, risk controls, or the robustness of the infrastructure. We’re laying the foundations for the dollar rails you’ll use and own.
Solomon
Make every dollar earn
Website | @solomon_labs on X | Discord | Docs
 | A guest post by
|