# Solomon Docs > USDv (Solomon's treasury-backed, rewards-bearing stablecoin), USDv for Businesses (Programmable Monetary Policy for your product), and the Platform (plug-and-play PMP infrastructure for issuers). Full content of every page, in navigation order. Source: https://docs.solomonlabs.org --- # USDv: USDv URL: https://docs.solomonlabs.org/usdv # USDv USDv is Solomon's productive onchain dollar. It is a synthetic stablecoin designed to track the U.S. dollar while remaining liquid, transferable, and composable as a single user-facing asset. Most stablecoins separate the dollar from the economics beneath it. Users receive a liquid onchain dollar, while the value generated by the reserve layer is captured elsewhere. Yield-bearing alternatives often solve this by introducing wrappers, staked tokens, vault receipts, or lockups, which weakens the dollar's usability. USDv is built to preserve both: the utility of a stablecoin and the economics of the reserve system. Eligible holders can participate in reserve-driven economics without staking, wrapping, locking, or moving into a separate instrument. They continue to hold and use USDv as the base dollar asset across wallets, applications, liquidity venues, DeFi protocols, custodians, and partner platforms. USDv is backed by a reserve portfolio of short-dated U.S. Treasuries and selected dollar-denominated stablecoins. Solomon's policy infrastructure tracks ownership, determines eligibility, and routes rewards without changing how holders use the asset. This allows USDv to remain simple at the user layer while becoming more expressive at the economic layer. In simple terms, USDv preserves the full utility of a liquid, composable dollar while allowing eligible holders to earn in its default state. > Token Address: [`USDvUSpnhCr9yBgj3UyVrD239HRUv4RsHwH2FxsWuMk`](https://solscan.io/token/USDvUSpnhCr9yBgj3UyVrD239HRUv4RsHwH2FxsWuMk) --- # USDv: The USDv Thesis URL: https://docs.solomonlabs.org/usdv/thesis # The USDv Thesis The onchain dollar has a structural flaw. Stablecoins made dollars liquid, transferable, and programmable. But they did not make the dollar economically complete. In the dominant model, users receive the utility of the dollar while the economics of the reserve system accrue elsewhere. The token moves through wallets, exchanges, applications, and protocols, but the value generated beneath it is captured by issuers, platforms, intermediaries, or secondary products. To earn, users are pushed out of the base dollar and into wrappers, vaults, staked tokens, lending markets, bridges, strategy contracts, and structured positions. Much of this is not the pursuit of exotic return. It is the repackaging of baseline dollar-market economics, often comparable to short-duration Treasury returns, through additional smart contract and product risk. That is the wrong architecture. Every added layer introduces new contracts, dependencies, liquidity assumptions, withdrawal mechanics, governance risk, and failure modes. Billions of dollars have been lost across crypto exploits, hacks, and protocol failures. Not all of those losses came from yield products, but the pattern is clear: every extra layer users must touch becomes another surface for risk. USDv is built from a different premise: the dollar should not have to become a position in order to become productive. USDv is a single-token synthetic stablecoin designed to track the U.S. dollar, remain liquid and composable as a base asset, and allow eligible holders to earn without leaving that asset. USDv has three layers: - **The asset layer**: USDv is the dollar token users hold, transfer, and use. - **The reserve layer**: USDv is backed by high-quality dollar assets, including USDG, USDC, and short-dated U.S. Treasury bills. - **The policy layer**: Solomon attributes eligible USDv activity and routes rewards across supported wallets, venues, custodians, and integrations. USDv is not a wrapper, vault receipt, staked token, or lending position. USDv is the base dollar asset, with eligibility, attribution, and reward routing handled beneath it. USDv restores the economics of the dollar to the dollar itself. --- # USDv: How USDv Works URL: https://docs.solomonlabs.org/usdv/how-it-works # How USDv Works USDv works like a normal stablecoin at the user layer. You acquire it, hold it in a wallet, transfer it, or use it through supported applications and protocols. To participate in eligible rewards, a user completes a one-time opt-in transaction. This proves wallet ownership and allows the user to configure where rewards should be routed. After opt-in, supported USDv balances and positions associated with that wallet can be recognized by Solomon's policy infrastructure. The user does not need to stake, wrap, lock, or convert USDv into another instrument. The system works in four steps: The result is a stablecoin that preserves full liquidity and composability while allowing eligible holders to earn in its default state. --- # USDv: Reward Routing URL: https://docs.solomonlabs.org/usdv/reward-routing # Reward Routing USDv separates where principal is held from where rewards are received. You can hold USDv in one wallet and send rewards to that wallet or to a different destination. The underlying USDv does not need to move. ## Principal Wallet The wallet associated with the USDv balance or supported USDv position. It remains under the holder's control. ## Reward Destination The wallet selected to receive rewards. It can be the principal wallet or another wallet. Common configurations include: - a cold wallet holds USDv and a hot wallet receives rewards - a treasury holds principal and an operating wallet receives rewards - an application uses USDv and its owner wallet receives rewards - a market maker holds USDv across supported venues and routes rewards to a central wallet ## Delivery Options Rewards can: - **Accrue for claim**: rewards accumulate until the holder claims them. - **Be delivered over time**: rewards are sent to the selected destination based on schedule. Reward routing changes where rewards go. It does not change ownership of the principal or make an unsupported position eligible. When rewards are received and held as USDv, they become part of the eligible balance as well. This allows rewards to compound across both the principal wallet and the destination wallet. --- # USDv: Example: Route Rewards to Spend Wallet URL: https://docs.solomonlabs.org/usdv/example-cold-to-spend # Example: Route Rewards to Spend Wallet A user holds 100,000 USDv in a cold wallet. They want to keep principal in self-custody, but route rewards to a wallet they actually use, such as a hot wallet, neobank wallet, or card-linked spend wallet. With USDv, the user keeps the principal wallet untouched and selects a separate reward destination. ## Example - **Principal wallet**: 100,000 USDv - **Reward destination**: neobank spend wallet - **Reward mode**: stream - **Expected earn rate**: 4% - **Estimated annual rewards**: 4,000 USDv - **Estimated monthly rewards**: 333 USDv The 100,000 USDv remains in the cold wallet. Rewards stream to the spend wallet. Balances are accounted for across both the principal wallet and destination wallet, allowing streamed USDv rewards to compound across the combined position. --- # USDv: Example: USDv in a Lending Pool URL: https://docs.solomonlabs.org/usdv/example-lending-pool # Example: USDv in a Lending Pool Lending markets are inefficient when stablecoin liquidity sits idle. In a typical lending pool, suppliers earn lending interest only when assets are borrowed. If borrow demand is low, part of the stablecoin pool remains unused and earns nothing. USDv changes that. A user can supply USDv to a supported lending pool and continue earning the USDv base rate on eligible USDv exposure, including idle USDv sitting inside the pool. ## Lending Pool Example A supported lending pool has: - **Total USDv supplied**: 10,000,000 USDv - **USDv borrowed**: 6,000,000 USDv - **Idle USDv liquidity**: 4,000,000 USDv - **Expected earn rate**: 4% In a normal stablecoin pool, the idle 4,000,000 USDv waits for borrow demand. With USDv, that idle liquidity earns. At a 4% expected earn rate, the idle 4,000,000 USDv generates 160,000 USDv of annualized rewards before lending interest. This creates a more efficient lending market: - suppliers earn while liquidity waits for borrowers - pools can stay deeper without leaving idle capital unproductive - borrowers still benefit from available liquidity - rewards can be routed to a separate destination wallet - the destination wallet also compounds as rewards arrive in USDv ## Example A user supplies 100,000 USDv to the lending pool. - **Lending position**: 100,000 USDv - **Reward destination**: treasury wallet - **Expected earn rate**: 4% - **Estimated annual USDv rewards**: 4,000 USDv - **Estimated monthly USDv rewards**: 333 USDv The user keeps the lending position active. USDv rewards route to the treasury wallet, where they continue compounding as USDv. --- # USDv: Example: Market Maker Operating Wallet URL: https://docs.solomonlabs.org/usdv/example-market-maker # Example: Market Maker Operating Wallet Market makers often hold USDv across multiple venues and operational wallets. Today, the stable leg of a market-making position usually does not earn at the asset level. If stablecoin inventory is sitting inside a pool or operating wallet, that USD exposure is idle unless it is actively generating fees. USDv makes the stable leg productive. ## Example A market maker has USDv exposure across two LP positions and one operating wallet: - **SOL/USDv pool on Meteora**: position size 500,000 USDv equivalent, USDv leg 250,000 USDv - **WBTC/USDv pool on Orca**: position size 400,000 USDv equivalent, USDv leg 200,000 USDv - **Operating wallet**: USDv balance 150,000 USDv Across the full setup: - **USDv in LP positions**: 450,000 USDv - **USDv in operating wallet**: 150,000 USDv - **Total eligible USDv position**: 600,000 USDv - **Reward destination**: operating wallet - **Reward mode**: stream - **Expected earn rate**: 4% - **Annual USDv rewards**: 24,000 USDv The market maker keeps liquidity deployed in the Meteora and Orca pools while also holding USDv in its operating wallet. USDv accounts for the combined eligible balance across the LP positions and the operating wallet. Rewards from the full 600,000 USDv position stream to the operating wallet. As rewards arrive in USDv, they increase the operating wallet balance and compound across the total eligible position. --- # USDv: Acquire and Redeem USDv URL: https://docs.solomonlabs.org/usdv/acquiring-and-redeeming # Acquire and Redeem USDv USDv is available through open onchain liquidity and permissioned institutional flows. ## Swap Onchain Most users acquire or sell USDv through supported liquidity venues. You can swap between USDv and supported assets such as USDC or USDG without using the direct mint or redeem system. Market prices can vary by venue. Review price impact, fees, network costs, and available liquidity before submitting a transaction. ## Direct Mint Approved counterparties can mint USDv by transferring accepted reserve assets and receiving newly issued USDv. Direct minting is intended for eligible market makers, institutions, and partners. It requires onboarding, KYC or KYB, compliance review, and operational approval. Limits, supported assets, processing windows, and jurisdictional restrictions can apply. ## Direct Redeem Approved counterparties can redeem USDv by burning USDv and receiving an approved payout asset. Direct redemption is subject to onboarding, available liquidity, operational controls, program terms, and processing windows. Holding USDv does not by itself create access to direct redemption. --- # USDv: Reserves and Peg Stability URL: https://docs.solomonlabs.org/usdv/peg-stability-and-reserves # Reserves and Peg Stability USDv is designed to track the U.S. dollar through a reserve-based stability model. Each USDv is supported by a portfolio of dollar-denominated assets. The portfolio is managed to support onchain liquidity, approved redemptions, market operations, and the income used to fund rewards. ## Reserve Portfolio USDv reserves include USDG and USDC. Solomon is adding direct exposure to short-dated U.S. Treasuries, which is expected to become the primary reserve component. Stablecoin reserves provide liquidity for onchain access and settlement. Reserve composition can change based on supply, redemption needs, market liquidity, counterparty access, risk management, and program requirements. ## How the Peg is Supported - **Reserve assets**: dollar-denominated assets are held against outstanding USDv. - **Direct mint and redeem**: approved counterparties can create or redeem USDv under defined operational controls. - **Onchain liquidity**: supported markets allow users to buy and sell USDv. - **Liquidity management**: Solomon manages reserve liquidity and market operations based on how USDv is used. These mechanisms are designed to keep USDv liquid and close to one U.S. dollar. They do not guarantee that USDv will always trade at exactly $1 in every market. USDv is not a bank deposit or a money market fund share, and it is not guaranteed by a government agency. --- # USDv: Transparency and Risk URL: https://docs.solomonlabs.org/usdv/transparency-and-risk # Transparency and Risk USDv involves reserve, market, counterparty, program, and integration risk. Review the available disclosures before acquiring or using it. ## Transparency The USDv dashboard is intended to show: - outstanding USDv supply - reserve composition and reserve ratio - stablecoin and U.S. Treasury exposure - supported liquidity venues and DeFi integrations - reward eligibility and routing activity - reports, attestations, and relevant program addresses [View USDv Reserves](https://app.solomonlabs.org/stats) ## Principal Risks - **Peg risk**: USDv can trade above or below $1 in secondary markets. - **Liquidity risk**: available liquidity and exit costs can vary by venue and market conditions. - **Reserve asset risk**: USDG, USDC, U.S. Treasuries, and other reserve assets carry issuer, custody, settlement, market, operational, and regulatory risk. - **Counterparty risk**: USDv can depend on custodians, banks, stablecoin issuers, market makers, and other service providers. - **Solana program risk**: bugs, vulnerabilities, upgrades, or operational errors can affect USDv and related infrastructure. - **Integration risk**: applications and protocols that support USDv introduce their own risks. - **Program risk**: rewards depend on eligibility, attribution, policy configuration, funding, and settlement operations. - **Regulatory risk**: access, rewards, minting, redemption, and integrations can vary by jurisdiction. Rewards are variable and not guaranteed. Supported venues, eligibility rules, and rates can change. USDv is not a bank deposit. It is not a money market fund share. It is not guaranteed by any government agency. [USDC Risk Disclosure](https://www.circle.com/legal/usdc-risk-factors) [USDG Risk Disclosure](https://www.paxos.com/terms-and-conditions/risk-disclosures) [USDv Terms & Risk Disclosure](https://solomonlabs.org/terms-of-use) --- # USDv: Audits and Security URL: https://docs.solomonlabs.org/usdv/audits-and-security # Audits and Security Solomon uses external reviews, remediation verification, internal testing, and ongoing adversarial review before and after major releases. Security reviews reduce risk. They do not eliminate it. ## USDv Program ## USDv Program (Deprecated) --- # USDv for Businesses: USDv for Businesses URL: https://docs.solomonlabs.org/usdv-for-businesses # USDv for Businesses ## Control the economics of USDv inside your business Stablecoins made dollars easier to move, hold, and settle. But the economics generated by those dollars usually accrue somewhere else. USDv gives businesses a different model. USDv shares a portion of reserve revenue with eligible businesses. That revenue comes from the yield earned on the short-dated U.S. Treasuries backing USDv. Businesses participate based on the USDv balances they create, hold, or distribute. Solomon's Programmable Monetary Policy (PMP) infrastructure gives each business control over how that value moves inside its own app, platform, or operation. A business can decide how USDv economics are used: retained by the business, routed to customers, shared with partners, allocated to campaigns, tied to specific behaviors, and tracked with transparency and auditability. The business gets the economic control of an app-native stablecoin while using USDv as the shared stablecoin. No new branded stablecoin is required. Customers keep a liquid USDv balance. They do not need to stake, lock, wrap, or claim. > Token Address: [`USDvUSpnhCr9yBgj3UyVrD239HRUv4RsHwH2FxsWuMk`](https://solscan.io/token/USDvUSpnhCr9yBgj3UyVrD239HRUv4RsHwH2FxsWuMk) --- # USDv for Businesses: Control USDv Rewards URL: https://docs.solomonlabs.org/usdv-for-businesses/what-pmp-does # Control USDv Rewards Programmable Monetary Policy, or PMP, is Solomon's system for administering USDv rewards inside a business. PMP connects the USDv balances associated with the business to its eligibility, allocation, routing, and reporting rules. ## How it Works 1. **Connect balance sources**: identify the customer balances, treasury wallets, application accounts, and supported protocol positions associated with the business. 2. **Define a program**: set the objective, scope, funding model, duration, and settlement schedule. 3. **Apply policies**: determine which participants and balances qualify, how rewards are calculated, and what limits apply. 4. **Allocate and route rewards**: split available rewards between customers, the business, partners, or other approved destinations. 5. **Report the result**: record the balances observed, rules applied, amounts allocated, and settlement status. PMP calculates program outcomes offchain and executes approved distributions through onchain programs. This allows a business to change commercial rules without rebuilding every rule directly into a smart contract. --- # USDv for Businesses: How Rewards Are Funded URL: https://docs.solomonlabs.org/usdv-for-businesses/how-usdv-economics-work # How Rewards Are Funded USDv's reserve portfolio generates income, primarily from short-dated U.S. Treasuries as that exposure is added to the reserve. Solomon can use a portion of reserve income to fund rewards under an eligible business program. The business then uses Programmable Monetary Policy to decide how the available reward amount is allocated. ## Source and Allocation Are Separate **Source**: income generated by the USDv reserve portfolio provides the economic basis for rewards. The business can decide to add an additional funding source if needed. **Allocation**: the business program determines who receives rewards, how much each participant receives, where rewards are sent, and when they settle. A business can retain all available rewards, send them to customers, split them with partners, or combine them with an additional campaign budget. Rewards are not a direct claim on reserve income and are not a guaranteed pass-through of Treasury yield. Reward rates, program funding, and allocations are variable and can change under the applicable terms. --- # USDv for Businesses: Balance Sources URL: https://docs.solomonlabs.org/usdv-for-businesses/balance-sources # Balance Sources A balance source is a supported location where USDv associated with the business is held or used. Common balance sources include: - customer wallets or application accounts - business treasury and operating wallets - custody or exchange accounts - balances held by an onchain program - liquidity positions - lending or vault positions - collateral or margin accounts Solomon connects each supported source to the relevant business, participant, and program. For DeFi positions, state awareness is used to resolve the underlying USDv exposure rather than reading only the wallet's direct balance. Balance sources define what PMP can observe. They do not determine whether the balance qualifies. Eligibility and allocation are applied by the program's policies. Support is integration-specific. Contact the Solomon team to review protocol and custody coverage. --- # USDv for Businesses: Programs URL: https://docs.solomonlabs.org/usdv-for-businesses/programs # Programs A program organizes USDv rewards around a business objective. Programs can run continuously or for a fixed period. A business can operate multiple programs at the same time, including programs that apply to the same USDv balance under different rules. ## Continuous Programs Use a continuous program for an ongoing product feature. **Example**: reward eligible customers for maintaining USDv balances in an application. ## Fixed-Term Programs Use a fixed-term program for a campaign or event. **Example**: offer a one-time reward to targeted customers who deposit at least 250 USDv during a 90-day campaign. ## Program Configuration A program defines: - the business objective - included balance sources - eligible participants - funding source and budget - allocation and split model - reward destinations - settlement schedule - start and end dates - limits and controls A program is the container. Policies are the rules applied inside it. --- # USDv for Businesses: Policies URL: https://docs.solomonlabs.org/usdv-for-businesses/policies # Policies Policies are the rules PMP applies inside a program. A policy can use approved onchain state, business data, customer status, or external inputs. The rule set determines who qualifies, what USDv exposure counts, how rewards are calculated, and where settlement goes. ## Eligibility policies Eligibility policies define who or what qualifies. Examples: - KYC-approved customers only - minimum balance required - supported jurisdictions only - specific customer tiers - allowlists - denylists - account status requirements ## Trigger policies Trigger policies define events or external inputs that activate a rule. A trigger can come from onchain activity, offchain business data, or an approved external data source. ### Examples of onchain triggers - customer provides liquidity to an approved pool - customer holds USDv in a specific smart contract - customer uses USDv as collateral in an approved market - customer reaches a volume threshold onchain - customer interacts with a specific Solana program - customer swaps for a specific token ### Examples of offchain triggers - customer completes onboarding - customer reaches a card spend threshold - customer is assigned to a partner campaign - customer belongs to a specific product tier - customer completes an action tracked by the business ### Examples of external data inputs - approved partner attribution data - liquidity or market data - account status - campaign qualification data - oracle-fed market information Trigger policies make Programs more flexible. They let a business tie USDv economics to behavior inside its product, not just to passive balances. ## Allocation policies Allocation policies define how much value is assigned. Examples: - base reward allocation - boosted allocation for a campaign - higher allocation after a trigger event - higher allocation for a customer tier - higher allocation for a partner segment ## Split policies Split policies define who receives what share. Examples: - 100% to customers - 100% to the business - 80% to customers and 20% to the business - 70% to customers, 20% to the business, 10% to a partner ## Routing policies Routing policies define where rewards go. Examples: - customer wallet - app account - business treasury - rewards wallet - partner wallet - campaign wallet ## Schedule policies Schedule policies define when rewards settle. Examples: - weekly - biweekly - monthly - at the end of a campaign - after a trigger event is verified ## Tranche policies Tranche policies define tiered treatment. Examples: - balances above 1,000 USDv receive a higher allocation - balances above 10,000 USDv receive a higher allocation - customers in a higher product tier receive a higher allocation - balances held for longer receive a higher allocation - customers who complete a trigger event move into a higher tier ## One-time policies One-time policies define event-based rewards. Examples: - first deposit - first card transaction - account activation - campaign completion - minimum balance reached - first liquidity provision to an approved market --- # USDv for Businesses: Reporting & Auditability URL: https://docs.solomonlabs.org/usdv-for-businesses/reporting # Reporting & Auditability PMP maintains one record from observed USDv state through reward settlement. A business can review: - total USDv tracked by each balance source - USDv that qualified and did not qualify - the policy version applied - rewards accrued, allocated, and settled - amounts retained by the business - amounts sent to customers, partners, or agents - the destination and status of each settlement - program performance by customer, segment, or source ## Explain Every Result For each allocation, the business should be able to answer: - What USDv exposure was observed? - Who qualified? - Which policies applied? - How was the amount calculated? - How was it divided? - Where was it sent? - Did settlement complete? Because state, policy, attribution, and settlement use the same underlying record, reporting does not need to be reconstructed from separate systems after the fact. --- # USDv for Businesses: Example: Self-Custody Neobank URL: https://docs.solomonlabs.org/usdv-for-businesses/example-neobank # Example: Self-Custody Neobank ## Business Goals A neobank wants to use USDv as the dollar balance inside its app. It wants to: - grow customer balances - improve retention - reward eligible customers - keep a share of USDv economics - run targeted campaigns - keep balances liquid and spendable ## Setup The neobank integrates USDv into its app. Customers hold USDv in their app accounts. The neobank connects its relevant balance sources to PMP: - customer USDv balances - treasury wallet - rewards wallet The neobank creates two Programs inside PMP: - a continuous balance rewards Program - a 90-day deposit campaign ## Program 1: Ongoing Balance Rewards The neobank creates an ongoing Program for customer USDv balances. The goal is to reward eligible customers for maintaining balances while allowing the neobank to retain a defined share. Example rules: - customers must be KYC-approved - customers must hold at least 100 USDv - balances are measured over time - rewards settle every 14 days - 80% routes to eligible customers - 20% routes to the neobank Optional tiers: - balances above 1,000 USDv receive a higher allocation - balances above 10,000 USDv receive a higher allocation - balances above 50,000 USDv receive a higher allocation Result: Customers have a reason to hold USDv in the app. The neobank controls how much value customers receive and how much the business keeps. ## Program 2: Deposit Campaign The neobank creates a 90-day Program to drive new deposits. The goal is to increase funded accounts and new customer balances. Example rules: - campaign runs for 90 days - eligible customers are new or targeted customers - customer must deposit at least 250 USDv - customer receives a one-time bonus - bonus is funded from the neobank's rewards wallet - PMP reports funded accounts, reward cost, and retained balances Result: The neobank can run a targeted growth campaign without changing its ongoing balance rewards Program. ## Outcome The neobank controls the economics of USDv inside its app. Customers keep liquid USDv balances. The neobank gets revenue sharing, configurable rewards, campaign management, reporting, and auditability without launching its own stablecoin or building its own policy infrastructure. --- # USDv for Businesses: Compliance and Eligibility URL: https://docs.solomonlabs.org/usdv-for-businesses/compliance-and-eligibility # Compliance and Eligibility USDv for Businesses is permissioned. A business must complete onboarding before it can use PMP. Eligibility can vary by: - business - market - customer type - jurisdiction - wallet - account status - Program - policy configuration A customer or balance may be ineligible even if it holds USDv. Some policies may be locked by Solomon. Locked policies can include restricted address exclusions, unsupported jurisdiction exclusions, minimum compliance requirements, and review requirements. The business cannot override locked policies. Customers do not stake, lock, or wrap USDv to participate in a Program. USDv remains liquid unless the business's own product imposes separate restrictions. USDv backing, reserve composition, redemption mechanics, eligible counterparties, and risk controls are covered in the Transparency and Risk documentation. --- # Platform: The Solomon Platform URL: https://docs.solomonlabs.org/platform # The Solomon Platform ## One system for administering programmable asset economics Onchain assets move across wallets, applications, custodians, exchanges, and DeFi protocols. The systems used to administer their economics often lose context as the asset moves. An issuer still needs to determine: - what asset exposure exists - who qualifies - what value each participant is entitled to - where that value should go - how the result should be settled and reported Today, those functions are often divided across protocol data providers, custom integrations, internal databases, calculation scripts, payment systems, and reporting tools. That fragmentation limits what an issuer can offer. Economic Programs become tied to a particular wallet, product, or venue because the systems administering them cannot preserve context as the asset moves. Solomon provides a different model. The Solomon Platform is a unified, state-aware system for observing an asset, applying issuer-defined policy, attributing economics, routing settlement, and reporting the outcome. This allows issuers to administer Programs across the places their asset is actually used, without building a separate operating system for every protocol, partner, or campaign. Solomon gives issuers the infrastructure to control how defined economics are recognized, allocated, routed, and reported. The Platform is designed for issuer-controlled assets with recurring or event-based economics. These docs explain the model at a nontechnical level. [Contact the Solomon team](mailto:platform@solomonlabs.org) for a demo or implementation discussion. --- # Platform: Programmable Monetary Policy URL: https://docs.solomonlabs.org/platform/rewards-model # Programmable Monetary Policy ## From economic intent to operational policy Programmable Monetary Policy (PMP) is the core system of the Solomon Platform. PMP turns an issuer's economic intent into an operating Program. It connects the source of value to the asset states, participants, and destinations that should receive it. The core flow: - **Observe state**: identify the relevant balances, positions, accounts, and activity across approved sources. - **Apply policy**: determine which state qualifies and what rules apply. - **Attribute economics**: calculate what each participant is entitled to receive. - **Route settlement**: direct each allocation to its configured destination. - **Report outcomes**: record what qualified, which Policies applied, how value was divided, and where it went. Because each step operates on the same state and policy model, an issuer does not need to reconcile a different interpretation of the Program at every stage. Rewards are one use of PMP. The same system can administer other issuer-defined economics wherever value must be allocated according to state and policy. --- # Platform: State Awareness URL: https://docs.solomonlabs.org/platform/state-awareness # State Awareness ## Solomon understands positions, not only wallet balances Once an asset enters DeFi, the holder may no longer appear as the direct owner of the underlying token. Their exposure may sit inside a lending position, liquidity position, vault, collateral account, or another protocol structure. A system that reads wallet balances alone loses that context. Across supported integrations, Solomon remains fully state-aware. It understands the position the asset has entered, resolves the relevant underlying exposure, associates that exposure with the appropriate participant, and tracks how the state changes over time. This gives PMP the information needed to determine: - where the asset is - what position it occupies - who has economic exposure - how much exposure qualifies - what relevant activity has occurred State Awareness allows Policies to respond to the asset's actual use, not merely its top-level ownership. It also means users do not need to exit useful positions or enter new ones (staking, vaults, lockups) solely to remain visible to an economic Program. An asset can continue moving through supported applications and protocols while its eligible economics are administered beneath it. --- # Platform: Programs and Policies URL: https://docs.solomonlabs.org/platform/programs-and-policies # Programs and Policies A program organizes an asset's economics around a defined objective. A policy defines the rules used to administer that program. ## Programs A program connects: - an economic source - supported asset states and balance sources - eligible participants - a funding and allocation model - settlement destinations - a reporting period Programs can run continuously or for a fixed period. Multiple programs can operate on the same asset at the same time. ## Policies Policies determine: - which balances, positions, or activity count - which participants qualify - how exposure is measured - how value is allocated and divided - where each allocation is routed - when settlement occurs - which limits and controls apply Policies can use approved onchain state, business information, participant status, or external inputs. An issuer can use this model to support different partners, products, markets, and objectives without creating a new token, wrapper, ledger, or payout system for each arrangement. --- # Platform: Unified Administration URL: https://docs.solomonlabs.org/platform/unified-administration # Unified Administration Economic programs are difficult to operate when each stage uses a different system and a different interpretation of the underlying state. One provider identifies balances. Another interprets protocol positions. Internal logic determines eligibility. Separate infrastructure calculates allocations, executes payments, and reconstructs reporting after settlement. Even when each component works, policy changes must be reproduced across systems and every result must be reconciled back to the original state. Solomon administers the full lifecycle from one underlying record. For every outcome, an issuer can trace: - the state that was observed - the policy and version applied - the participant that qualified - the calculation used - the resulting allocation and split - the settlement destination - the settlement status Programs, policies, partner arrangements, permissions, funding, settlement, and reporting use the same model. When a policy changes, the change carries through attribution, settlement, and reporting without requiring a separate reconciliation process. The value of unified administration is not only automation. It is one coherent interpretation of the program across fragmented onchain markets. --- # Platform: Example: USDv URL: https://docs.solomonlabs.org/platform/usdv-in-practice # Example: USDv USDv is built and operated using the Solomon Platform. USDv is the asset users hold, transfer, and use. Its reserve portfolio provides the economic source for eligible rewards. The Platform administers the state, policy, attribution, routing, and reporting beneath it. ## State Awareness Solomon recognizes supported USDv exposure across wallets, applications, custody systems, liquidity positions, lending markets, collateral accounts, and partner integrations. ## Programmable Monetary Policy PMP applies the relevant USDv rules, determines who qualifies, calculates each allocation, and separates where principal is held from where rewards are received. ## Settlement and Reporting Rewards are routed to configured destinations, and the resulting allocations and settlements are recorded from the same program state. ## One System Across the Product USDv is the liquid onchain dollar. [USDv for Businesses](/usdv-for-businesses) lets companies control how available rewards are used inside their products. The Solomon Platform administers those arrangements across supported onchain states. Holders do not need a separate wrapper or staking token. Businesses do not need a separate reward ledger and payout system. Solomon does not need disconnected systems for consumer rewards, business programs, protocol integrations, eligibility, routing, and reporting. USDv demonstrates the platform thesis: keep the user-facing asset simple and move the operational complexity into one state-aware system beneath it. --- # Platform: Work with Solomon URL: https://docs.solomonlabs.org/platform/contact-team # Work with Solomon Platform implementations are configured with the Solomon team. An implementation begins by defining: - the asset and its economic source - the balances, positions, and protocols that should be recognized - the Programs and Policies that should apply - the participants and eligibility requirements - the settlement and reporting model These docs describe the Platform at a nontechnical level. [Contact the Solomon team](mailto:platform@solomonlabs.org) to request a demo, review protocol coverage, or discuss an implementation. --- # SOLO: Overview URL: https://docs.solomonlabs.org/solo # Overview SOLO is the ownership asset of Solomon. Solomon is structured around a single economic ownership layer. There is no separate private equity instrument with a competing claim on the value created by the organization. Instead, SOLO is designed to occupy the economic role that equity traditionally plays: providing exposure to the value of the organization and control over its major economic decisions. This structure is intended to keep ownership, governance, and value creation aligned around the same asset. ## Legal and economic structure Solomon operates through Solomon DAO LLC, the legal entity through which the organization's core assets and economic interests are held and administered. These include Solomon's: - intellectual property and technology - brand and associated rights - treasury assets and protocol-controlled liquidity - domains, documentation, and other digital property - contractual and economic rights held on behalf of the organization - assets acquired or developed over time SOLO holders govern this structure through onchain proposals. This differs from the common token and equity model in which token holders may govern a protocol while a separate company and private shareholder base own the technology, brand, commercial rights, or other assets through which value is created. Solomon does not maintain that competing ownership layer. ## Value accrual As Solomon builds products, technology, commercial relationships, treasury assets, and other sources of economic value, those interests remain within the owner-governed structure. SOLO holders can determine how organizational capital is deployed, including reinvestment into growth, liquidity, acquisitions, incentives, token acquisitions, distributions, and other approved uses of capital. There is no requirement that value accrue through one fixed mechanism. Capital allocation can change as Solomon develops. The underlying principle is that the assets being built, the authority to allocate them, and the ownership asset should remain aligned. If Solomon creates durable value, SOLO is the asset through which that value is intended to be reflected. ## Token transparency Solomon maintains a B1 Token Transparency filing with Blockworks covering its organizational structure, intellectual property, token supply and allocations, fundraising, holder rights, market arrangements, economic structure, and material risks. [View Solomon's Blockworks B1 Filing](https://blockworks.com/token-transparency/filing/solomon) --- # SOLO: MetaDAO URL: https://docs.solomonlabs.org/solo/metadao # MetaDAO provides the market infrastructure through which SOLO was initially distributed and through which major Solomon decisions are made. It does not own Solomon's intellectual property, treasury, brand, or other organizational assets. Those sit within Solomon's own DAO structure. MetaDAO provides the mechanism through which SOLO owners exercise control over that structure. ## Initial ownership distribution SOLO launched through MetaDAO in November 2025. The Token Generation Event received approximately $102.9 million in commitments, of which $8 million was accepted in exchange for 10 million SOLO. The MetaDAO offering established SOLO as Solomon's ownership instrument from inception, with no parallel private equity round. [View Solomon on MetaDAO](https://www.metadao.fi/projects/solomon) [View the original SOLO offering](https://www.metadao.fi/projects/solomon/fundraise) ## Ongoing decision infrastructure Solomon continues to use MetaDAO's conditional decision markets for major DAO actions. Instead of asking token holders to vote yes or no, proposals create markets that price SOLO under each possible outcome. Participants can trade based on whether they believe a proposed action will increase or decrease the value of SOLO. This ties organizational decision-making directly to the ownership asset itself. --- # SOLO: Decision System URL: https://docs.solomonlabs.org/solo/governance-mechanics # Decision System ## Decisions priced in SOLO Major Solomon decisions are made through 's conditional decision markets rather than conventional token voting. Each active proposal creates two conditional markets: - **PASS**, representing the price of SOLO if the proposal is approved. - **FAIL**, representing the price of SOLO if the proposal is rejected. Participants trade according to their expectations for SOLO under each outcome. > A proposal therefore asks a specific economic question: is SOLO expected to be worth more if this action is taken? A proposal passes when the time-weighted PASS price exceeds the FAIL price by the required threshold. The default threshold is 1.5%. ## Scope of proposals Proposals can authorize material actions involving Solomon and its assets, including: - treasury spending and capital allocation - investments in products, operations, partnerships, or acquisitions - SOLO acquisition or distribution programs - changes to treasury-provided liquidity - additional SOLO issuance - incentive programs - changes to controlled token or organizational parameters The same system can be used as Solomon's needs evolve, without changing the underlying ownership structure. ## Proposal lifecycle Anyone can submit a proposal describing an action for Solomon to take. A proposal becomes active once the required amount of SOLO has been staked behind it. The default activation requirement is 500,000 SOLO. The stake functions as an anti-spam mechanism. It does not determine the outcome of the proposal and is not slashable. Only one proposal can be active at a time. Once activated, a proposal enters a three-day decision period. A portion of Solomon's spot liquidity is moved into conditional PASS and FAIL markets. Participants can then trade SOLO based on its expected value under each outcome. Trades associated with the eventual outcome settle normally. Trades associated with the alternative outcome revert. At the end of the decision period, the proposal is evaluated using time-weighted prices. If the PASS price exceeds the FAIL price by at least the required threshold, the proposal passes. Otherwise, it fails. Time-weighted pricing reduces the influence of short-lived price movements immediately before finalization. ## Example Assume Solomon is considering allocating $2 million of treasury capital to deepen SOLO liquidity. At the end of the decision period: - PASS-SOLO has a time-weighted price of $1.02. - FAIL-SOLO has a time-weighted price of $1.00. The market is valuing SOLO 2% higher if the proposal is approved. Because the difference exceeds the default 1.5% threshold, the proposal passes. The result is determined by the market's estimate of the proposal's impact on SOLO, rather than by a count of yes and no votes. --- # SOLO: Token Generation Event URL: https://docs.solomonlabs.org/solo/token # Token Generation Event The SOLO Token Generation Event took place through the platform from November 14, 2025 at 18:30 UTC through November 18, 2025 at 18:30 UTC. Participants committed $102,932,673 to the offering. Of that amount, $8 million was accepted in exchange for 10 million SOLO. This established SOLO's initial owner base and placed Solomon within MetaDAO's market-based ownership system from launch. ## Token structure | Allocation | SOLO | | --- | --- | | Token Generation Event | 10,000,000 | | SOLO liquidity pools | 2,900,000 | | Performance vehicle at launch | 0 | | Maximum performance vehicle | 12,900,000 | | Circulating supply at launch | 12,900,000 | | Total supply | 25,800,000 | The initial circulating supply consisted of the 10 million SOLO distributed through the Token Generation Event and 2.9 million SOLO allocated to liquidity pools. ## Performance vehicle Solomon's performance vehicle is designed to align long-term contributor economics with sustained increases in SOLO's market value. No tokens were distributed to the vehicle at launch. Up to 12.9 million SOLO can become available across five performance-based tranches: | Performance milestone | SOLO price | Tranche | | --- | --- | --- | | 2× | $1.60 | 2,580,000 SOLO | | 4× | $3.20 | 2,580,000 SOLO | | 8× | $6.40 | 2,580,000 SOLO | | 16× | $12.80 | 2,580,000 SOLO | | 32× | $25.60 | 2,580,000 SOLO | There is a minimum 18-month cliff before any performance allocation can unlock. Performance is measured using a three-month time-weighted average price, rather than a temporary spot price. The allocation therefore cannot be earned through time alone. It requires sustained SOLO performance, aligning contributor upside with the outcomes of other SOLO owners. ## Future issuance Additional SOLO cannot be issued unilaterally by the team. Any future issuance must be authorized through the same proposal process used for other material economic decisions. --- # SOLO: Resources URL: https://docs.solomonlabs.org/solo/resources # Resources | Resource | Details | | --- | --- | | Token type | Solana SPL token | | Token address | [`SoLo9oxzLDpcq1dpqAgMwgce5WqkRDtNXK7EPnbmeta`](https://solscan.io/token/SoLo9oxzLDpcq1dpqAgMwgce5WqkRDtNXK7EPnbmeta) | | Liquidity pool | [Meteora DAMM v2](https://www.meteora.ag/dammv2/2zsbECzM7roqnDcuv2TNGpfv5PAnuqGmMo5YPtqmUz5p) | | Trading and screener | [Jupiter](https://jup.ag/tokens/SoLo9oxzLDpcq1dpqAgMwgce5WqkRDtNXK7EPnbmeta) | | Market data | [CoinGecko](https://www.coingecko.com/en/coins/solomon) | | Decision markets | [Solomon on MetaDAO](https://www.metadao.fi/projects/solomon) | | Token Generation Event | [SOLO Token Generation Event](https://www.metadao.fi/projects/solomon/fundraise) | | Token transparency | [Blockworks B1 Token Transparency Filing](https://blockworks.com/token-transparency/filing/solomon) |