Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Solomon targets a structural gap in onchain dollars: stablecoins are liquid and composable, but the economics around them are usually separated from the dollar itself. Today, users often need to stake, wrap, lock, move into a vault, or hold a separate yield-bearing unit in order to earn or receive rewards. That fragments liquidity, breaks spendability, adds integration friction, and creates a worse user experience for wallets, protocols, treasuries, and payment applications.
Solomon’s goal is to make the dollar more programmable without making it less usable. USDv is designed to remain liquid, transferable, and spendable while allowing rewards and other economic flows to be routed according to transparent, configurable policies.
(b) Operational priorities
Solomon’s operational priorities are:
Maintain USDv stability, liquidity, and usability by expanding compliant issuance and redemption access, deepening onchain liquidity, monitoring peg conditions, and improving market structure.
Build Solomon’s programmatic monetary policy infrastructure, which allows rewards, yield, fees, incentives, partner attribution, and other economic flows to be routed around tokenized dollars and other eligible assets according to configurable policy logic.
Keep principal assets fully usable and composable while enabling economic flows to route to token holders, wallets, treasuries, LP positions, agents, partners, or other designated recipients without requiring wrappers, rebases, lockups, or separate staking units.
Support policy controls including permissioning, eligibility rules, designated reward recipients, routing logic, settlement cadence, attribution, reporting, and compliance-aware distribution requirements.
Operate USDv with a reserve and collateral framework focused on high-quality, transparent, and risk-managed assets, including short-duration Treasury exposure and other approved collateral or reserve assets where appropriate. Operational controls include custody segregation, transfer procedures, reconciliations, counterparty review, monitoring, and incident response.
Invest heavily in compliance, reporting, security, auditability, and control tooling, including permissioning, monitoring, governance controls, administrative procedures, and emergency response.
Use governance to allocate DAO treasury resources toward durable protocol capabilities, liquidity, integrations, compliance, and distribution rather than short-term emissions loops.
(c) High-level project overview
Solomon has two core primitives:
USDv: a stablecoin designed to remain stable, liquid, transferable, and fully spendable.
Programmatic monetary policy infrastructure: a policy and accounting layer that allows rewards, yield, fees, incentives, partner attribution, and other economic flows to be routed according to configurable rules while keeping the principal asset usable and composable.
The core idea is that the dollar should not need to stop being a dollar in order for the economics around it to become programmable. Instead of requiring users to stake, wrap, lock, or move into a separate yield product, Solomon enables economic flows to be attached to balances, wallets, treasuries, LP legs, agents, partners, or other designated recipients where enabled by policy.
USDv is designed to support integrations across wallets, protocols, neobanks, payment companies, and other onchain applications. Solomon’s infrastructure allows programs to define who is eligible, where rewards or economics should route, how settlement should occur, and what reporting or compliance requirements apply.
(d) Primary token functions
SOLO is Solomon’s governance token and ownership coin. There is no separate equity instrument for DAO ownership; SOLO is the primary ownership and governance surface.
SOLO holders participate in governance through MetaDAO-style futarchy markets. Governance may control treasury capital allocation, liquidity and incentive programs, DAO-approved service-provider relationships, token metadata actions, treasury strategy, integrations, grants, and other protocol-level decisions.
Value accrual to SOLO is expected to come through governance control over treasury resources, protocol strategy, and cashflow or economic rights controlled by the DAO. Treasury proceeds may be retained, reinvested, used for protocol growth, allocated to liquidity, used for incentives, or otherwise deployed as authorized by governance. Any distributions, buyback-like actions, or other tokenholder-directed economic programs would require appropriate governance approval.
(e) Control surface reliance
Governance is executed through MetaDAO-style futarchy markets using PASS/FAIL proposal markets. The DAO governance process controls major DAO-level decisions, including treasury allocation, incentives, service-provider engagement, protocol strategy, and other governance-approved actions.
Administrative control surfaces, including deployments, emergency actions, upgrade authority, pause authority, governance-executor authority, treasury execution, and program-level authority where applicable, rely on governance-approved operational structures such as multisigs, executors, committees, administrators, and explicit policy controls.
No individual contributor, Foundation actor, or DevCo has unilateral control over DAO governance, treasury assets, or protocol administration absent explicit authorization through DAO governance, contract, or an approved operational authority. The governance and control model may evolve through future governance decisions
Known Project Team
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Labs / DevCo
Full Name | Official Title | Prior Experience |
|---|---|---|
Hamza Choudhry | CEO | Founder of Solomon. Engineer with 10+ years of experience building critical systems for major airports and BlackBerry OS and developing EtherNet/IP standards. Founded XiWATT in 2017 to bring renewable energy yield onchain, followed by a stealth NFT lending protocol with eight figure volume. |
Joshua Richardson | CTO | Founder of Bamboo Relay, a leading 0x relayer. Built trading infrastructure across DeFi, CEXs, and onchain routing, including an FTX market-making operation with roughly $400M in monthly volume. Leads Solomon’s core engineering and infrastructure. |
Stephen Ptucha | Head of Growth | Led PayPal’s U.S. consumer crypto platform and PYUSD. Fintech operator across GE Capital, Synchrony, PayPal, and Venmo. Leads growth and partnerships at Solomon. |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Cobus Pietersen | Director | Independent Director of Solomon. Chartered Accountant and Accredited Director with 15+ years across Cayman governance and offshore finance. Formerly led fiduciary and crypto corporate-services practices at Walkers, with prior roles at Grant Thornton, KPMG, UBS, and MUFG. |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
Hamza Choudhry | Head Steward | Founder of Solomon. Engineer with 10+ years of experience building critical systems for major airports and BlackBerry OS and developing EtherNet/IP standards. Founded XiWATT in 2017 to bring renewable energy yield onchain, followed by a stealth NFT lending protocol with eight figure volume. |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
Solomon DAO is an entity under Marshall Islands DAO LLC. The DAO LLC is the primary legal holder and controller of the protocol and brand surface (core repos/codebases and associated brand assets).
(b) Contract/admin powers
Governance mechanism: Proposals are decided via MetaDAO futarchy PASS/FAIL markets, with execution gated by the onchain governance executor.
Proposal activation: An anti-spam activation stake is required to activate a proposal (non-slashing).
Treasury authority: Governance can authorize treasury spend, incentives, liquidity deployments, and other treasury actions exposed to the executor.
Admin authority: Operational control surfaces (including any pause/upgrade authorities where applicable) are held by a multisig, not individuals, and are used to execute governance outcomes and manage safety-critical operations.
(c) Locked-token rights (conditional)
No “lock SOLO for extra governance rights” system exists. The only described staking mechanic is the non-slashing proposal activation stake.
(d) Value accrual & holder rights
SOLO is an ownership coin. Value accrues to the token through governance control of treasury capital allocation and cashflows, with proceeds compounding into the treasury and reinvested unless governance authorizes distributions or buyback-like actions. There is no standing, automatic revenue distribution to holders absent governance authorization.
(e) Dissolution authority
Dissolution and wind-down authority sits with the Marshall Islands DAO LLC pursuant to its governing documents, and any wind-down of onchain assets would be initiated and authorized via an onchain governance action that directs the DAO LLC to execute the wind-down.
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Solomon Foundation, a Cayman Islands foundation entity.
(b) IP ownership & control
IP ownership & control: Solomon Foundation does not own or control the DAO’s protocol IP, core repositories/code, DAO treasury, or primary brand assets. Those assets are owned or controlled by Solomon DAO LLC, unless otherwise transferred, licensed, or authorized through DAO governance or contract. Solomon Foundation may use DAO-related IP or brand assets only to the extent authorized by Solomon DAO LLC, DAO governance, or applicable contractual arrangements.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Solomon Foundation does not have unilateral authority, veto rights, majority control, super-majority control, or other direct control over DAO governance or the DAO treasury. DAO and treasury actions are governed by Solomon DAO LLC’s governing documents and the applicable DAO governance process, including decision markets under the MetaDAO futarchy model.
(d) Powers over DevCo
Solomon Foundation does not have unilateral authority to direct Solomon DAO LLC, any DevCo, or any service-provider entity. The Foundation’s relationship with Solomon DAO LLC, DevCo entities, service providers, or committees is determined through DAO governance approvals, contracts, grants, or delegated authority frameworks.
(e) Contract/admin powers
Solomon Foundation does not have unilateral pause, upgrade, governance-executor, treasury-admin, or protocol-admin authority. Any such powers are governed by Solomon DAO LLC’s governance process and any DAO-approved executor, committee, multisig, or administrator structure.
(f) Current economic arrangements and distribution policies
N/A
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
No single Primary DevCo exists. Multiple separate, firewalled development or service-provider entities may provide services to the ecosystem, but they are not being designated as a Primary DevCo.
(b) IP ownership & control
N/A. No single Primary DevCo owns or controls the DAO’s protocol IP, core repositories/code, DAO treasury, or primary brand assets. Those assets are owned or controlled by Solomon DAO LLC, unless otherwise transferred, licensed, or authorized through DAO governance or contract. Development or service-provider entities may contribute work pursuant to contractual arrangements, but they do not own DAO IP unless expressly agreed in writing or approved through DAO governance
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
N/A. No single Primary DevCo has unilateral authority, veto rights, majority control, super-majority control, or other direct control over DAO governance or the DAO treasury. DAO and treasury actions are governed by Solomon DAO LLC’s governing documents and the applicable DAO governance process, including decision markets under the MetaDAO futarchy model.
(d) Powers over Foundation
N/A. No single Primary DevCo exists. Relationships with development or service-provider entities are coordinated through committees, contracts, or other authority structures established by Solomon DAO LLC and DAO governance. Any DevCo or service-provider entity is firewalled and does not have unilateral authority to direct Solomon Foundation or Solomon DAO LLC.
(e) Contract/admin powers
N/A. No single Primary DevCo has unilateral pause, upgrade, governance-executor, treasury-admin, or protocol-admin authority. Any such powers are governed by Solomon DAO LLC’s governance process and any DAO-approved executor, committee, multisig, or administrator structure.
(f) Current economic arrangements and distribution policies
N/A
Token Supply & Allocations
Initial Allocation
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SOLO | 2025-11-18 | MetaDAO ICO Public Sale | Public / Sale | 38.76% | 10,000,000 | 100.00% | 10,000,000 | 0 | 0.00% | 0 | 1 | Yes | 10,000,000 SOLO distributed to onchain MetaDAO ICO participants at $0.80 per SOLO. | |
SOLO | 2025-11-18 | Liquidity Provisioning | Liquidity | 11.24% | 2,900,000 | 100.00% | 0 | 0.00% | 0 | 1 | Yes | 2,900,000 SOLO reserved for DEX liquidity and market structure support at launch. | ||
SOLO | 2025-11-18 | PV Reserve 2x FDV | Treasury | 10.00% | 2,580,000 | 0.00% | 18 | 0.00% | 0 | 1 | Conditional | Performance Vehicle reserve tranche 1 of 5; earned only when protocol reaches 2x FDV vs. ICO valuation. | ||
SOLO | 2025-11-18 | PV Reserve 4x FDV | Treasury | 10.00% | 2,580,000 | 0.00% | 18 | 0.00% | 0 | 1 | Conditional | Performance Vehicle reserve tranche 2 of 5; earned only when protocol reaches 4x FDV vs. ICO valuation. | ||
SOLO | 2025-11-18 | PV Reserve 8x FDV | Treasury | 10.00% | 2,580,000 | 0.00% | 18 | 0.00% | 0 | 1 | Conditional | Performance Vehicle reserve tranche 3 of 5; earned only when protocol reaches 8x FDV vs. ICO valuation. | ||
SOLO | 2025-11-18 | PV Reserve 16x FDV | Treasury | 10.00% | 2,580,000 | 0.00% | 18 | 0.00% | 0 | 1 | Conditional | Performance Vehicle reserve tranche 4 of 5; earned only when protocol reaches 16x FDV vs. ICO valuation. | ||
SOLO | 2025-11-18 | PV Reserve 32x FDV | Treasury | 10.00% | 2,580,000 | 0.00% | 18 | 0.00% | 0 | 1 | Conditional | Performance Vehicle reserve tranche 5 of 5; earned only when protocol reaches 32x FDV vs. ICO valuation. |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(d) Planned but not yet executed airdrop
N/A
(d) Executed airdrop
N/A
(e) No airdrop planned or conducted
We have never conducted an airdrop to date and do not plan to execute one
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
No MM Deals | N/A | N/A | N/A |
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
No CEX/DEX Deals | N/A | N/A | N/A |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
No prior fundraising, OTC, or discounted MM sales have occurred. | N/A | N/A | N/A | N/A |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-06-29
(b) Exploit vector summary
N/A
(c) Quantified impact
N/A
(d) Remediation/response taken
N/A
(e) Current status
N/A
(f) References (optional)
N/A
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
- (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
- Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
- Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
- Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
- Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
- (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
- Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
- Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
- (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
- Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
- Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
N/A
(b) Protocol, Technology & Security Risks
Solomon’s protocol and smart contracts may contain undiscovered bugs, design flaws, or implementation errors. Potential failure areas include authorization logic, minting and redemption controls, asset accounting, eligibility determination, economic routing, upgrade procedures, emergency controls, and the interpretation of positions held across supported DeFi protocols. A defect in these areas could result in unauthorized actions, incorrect balances or rewards, misrouted economics, assets becoming temporarily inaccessible, delayed minting or redemption, or, in a severe case, loss of funds or the issuance of USDv without corresponding reserves.
The protocol is deployed on Solana and is therefore also exposed to risks arising from the underlying network. These include network congestion or outages, validator or client software defects, transaction-ordering issues, runtime changes, account contention, and failures or inconsistencies among RPC providers and indexing services. Such events could delay or prevent transfers, minting, redemption, policy updates, or other protocol operations even where Solomon’s contracts are functioning as intended.
Solomon also interacts with external systems and protocols. Changes, bugs, exploits, insolvency, or unexpected behavior in supported wallets, custodians, token programs, decentralized exchanges, lending markets, liquidity positions, price feeds, or other integrations could affect the protocol’s ability to accurately identify ownership and state, administer economic programs, or support orderly liquidity and redemption. A third-party protocol may change its account structure or position semantics in a manner that causes Solomon’s state-tracking logic to become incomplete or inaccurate. Native USDv operations on Solana do not require a rollup, and bridge-related risk applies where users or partners independently use third-party bridging infrastructure.
Solomon has completed security audits and reviews with Accretion, Cantina, and independent auditors. The protocol has also undergone internal testing and adversarial review, and Solomon participates in the Solana Stride program and follows the security standards and development practices established through that program. The architecture further limits risk through constrained authorities, explicit permissions, and operational controls governing minting, redemption, upgrades, freezes, and other sensitive actions.
These measures reduce risk but cannot eliminate it. Audits and security reviews are point-in-time assessments based on the code, assumptions, integrations, and deployment configuration reviewed. They may fail to identify subtle logic errors, economic attacks, unexpected interactions between contracts, vulnerabilities introduced by later upgrades, compromised administrative credentials, operational mistakes, social engineering, novel attacks against Solana, or failures in third-party infrastructure. Audits also do not constitute formal proof that the protocol is correct or that funds cannot be lost.
Solomon will continue to subject material code changes to testing and security review, restrict and monitor privileged operations, and update its controls as the protocol and its integrations evolve. Nevertheless, users should understand that smart-contract systems and blockchain networks remain experimental technologies and may fail in ways that cannot be fully anticipated or prevented.
(c) Token Economics, Unlocks & Incentive Risks
N/A
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Solomon is solely responsible for the content, accuracy, and legality of its disclosures.