GM Markets
Whitepaper
Capital markets on permissionless rails
A formal design document covering the tokenization model, custody architecture, vault framework, execution model, governance, continuity, and verification layer.
- Version
- 1.0
- Published
- 2026-05-04
- Authors
- GM Markets team
Contents
- Abstract3
- Introduction and motivation4
- Related work5
- System architecture6
- Tokenization model7
- Custody architecture8
- Trade execution: RFQ via broker hedge9
- Order types and the keeper10
- Vault framework11
- Pricing12
- Verification layer13
- Smart contract design and safety14
- Governance and emergency controls15
- Continuity and wind-down16
- Limitations and open problems17
- References18
Abstract
GM Markets is a permissionless interface for tokenized public-asset markets and on-chain yield vaults. The system separates a regulated issuance layer (operated by Flo, an independent infrastructure issuer) from the user-facing trading and allocation interface (GM Markets). Tokenized public instruments are backed 1:1 by underlying assets held in segregated accounts at regulated prime brokers and mirrored as ERC-20 tokens across Ethereum, Base, and Arbitrum. Vault capital is custodied via multi-party computation (MPC) signing, with no externally-owned account holding protocol funds. Reserve integrity is attested by an independent provider on a regular cadence and verifiable on-chain via signed proofs. A bankruptcy-remote structure with an independent collateral agent isolates token holders from operator insolvency. On a wind-down trigger, the MPC quorum transitions to redemption-only and the collateral agent administers investor claims directly from the isolated estate. The combination of regulated issuance, broker-custodied reserves, MPC vault custody, and independent collateral agency produces a capital-markets substrate with failure modes that are bounded rather than trust-dependent.
1. Introduction and motivation
Tokenized real-world assets today face a fork in design. They either onboard end-users with KYC at the interface level, capping the addressable user base to existing brokerage demographics, or they route users to a partner exchange to avoid that obligation. The first path inherits the friction of legacy brokerage onboarding. The second introduces a counterparty between the user and the issuer.
GM Markets takes a third path. The regulatory burden sits at the issuance layer where it legally must (Flo, the issuer, performs counterparty diligence on the entities that mint tokens against underlying assets). The user-facing interface is permissionless: any compatible wallet can connect, transact, and self-custody. The user holds a bearer token, and the eligibility check is enforced at the issuance leg, not the secondary market.
This design is structurally similar to the staking-protocol pattern in proof-of-stake networks: the protocol does not KYC stakers, and the regulated obligations live with the validator operators that the protocol relies on. We refer to this as a Lido-for-RWA architecture.
The product surface is two things, sharing one wallet path. Trading covers tokenized stocks, ETFs, commodities, FX, and crypto across over 8,000 instruments. Allocation covers on-chain yield vaults across one issuer role and six manager strategy subtypes. Both are spot only. There is no leverage, no perpetuals, and no funding rate.
2. Related work
Tokenized RWA platforms today fall into four structural categories.
Permissioned-only RWA platforms gate access at the user level via KYC and accreditation checks before any deposit. They preserve the regulatory comfort of legacy brokerage but exclude the permissionless DeFi user.
KYC-gated brokerage frontends mint tokens but require interface-level user onboarding identical to a regulated brokerage. They duplicate the regulatory obligation at two layers (issuer and frontend) without adding additional structural protection.
Partner-exchange-routed venues sidestep frontend KYC by handing users off to a third-party exchange. This adds a counterparty between user and issuer and concentrates redemption capacity in the routing partner.
Fully-on-chain RWA without prime-broker backing relies on bankruptcy treatment of off-chain wrappers (a foundation, a trust, or a permissioned issuer) without segregation at a regulated custodian. Bankruptcy-remoteness is asserted but not always operationally testable.
GM Markets combines the permissionless property of the on-chain category with the segregated-prime-broker custody of the regulated brokerage category, holding the regulatory burden at the issuance layer rather than the user-facing interface.
3. System architecture
The system consists of three layers with explicit trust boundaries between them.
Issuance layer
Flo operates the issuance pipeline: counterparty onboarding for the entities that mint tokens, segregated holdings at regulated prime brokers for the underlying assets, regulatory reporting, and the bankruptcy-remote structure that isolates token holders from operator insolvency. This layer carries the regulatory obligation. The user does not interact with it directly.
Interface layer
GM Markets is the user-facing application: market discovery, charting, order entry, vault allocation, portfolio views, and a request-for-quote (RFQ) router that connects user intent to the issuance layer's pricing and minting. The interface is permissionless, holds no user funds, and collects no PII at the GM Markets layer.
On-chain layer
Standard ERC-20 tokens for tokenized assets and vault shares on Ethereum, Base, and Arbitrum. Smart contracts for vault accounting, fee distribution, and emergency controls. A 5-of-9 multi-sig owns the contracts, with a 48-hour timelock on every administrative change. Vault capital is custodied via 3-of-5 MPC signing, with no externally-owned account in the path.
Properties
Three observations follow from this layering. First, no single layer's failure causes user-fund loss in a single step. Second, the user's trust in the interface is bounded: even if the GM Markets domain disappears, tokens remain on-chain and redemption proceeds through the issuance layer directly. Third, the interface layer can iterate on UX without touching the issuance or contract surfaces.
4. Tokenization model
Tokenized public-asset positions are issued as bearer ERC-20 tokens against underlying held in segregated accounts at regulated prime brokers. Crypto assets are native and have no broker leg.
For each tokenized public instrument, the issuance flow is: a counterparty-onboarded entity deposits the underlying with the issuer's prime broker, the issuer mints a corresponding ERC-20 amount, and the token enters the secondary market. Issuance is bounded by jurisdictional eligibility rules set per asset; a token will not mint into a wallet whose connection fails the per-asset eligibility check at the issuance leg. Once minted, the token is bearer and transfers freely on-chain. The eligibility gate is not enforced on secondary transfer.
Holders have a direct contractual entitlement to the underlying held at the regulated prime broker, not a claim on any operating-entity balance sheet. That claim is implemented through a bankruptcy-remote structure with an independent director and an independent collateral agent. If the operating entity becomes insolvent, the assets backing the tokens are not part of the operating entity's bankruptcy pool; the collateral agent administers redemption directly from the isolated estate.
This structure is materially different from a vault-of-claims model in which token holders own claims against an operating entity. In a vault-of-claims model, operating-entity insolvency creates a creditor queue. In the structure used here, operating-entity insolvency triggers redemption from a structure outside the operating-entity estate.
5. Custody architecture
Custody is split by asset class. The split occurs at the issuance layer, not at the user-onboarding layer. Users are always self-custodial regardless of what they hold.
- Tokenized public assets (stocks, ETFs, commodities, FX) are backed 1:1 by the underlying held in segregated accounts at regulated prime brokers. Reconciliation runs continuously and is published in the live transparency surface.
- Crypto assets are native to the underlying chain. There is no prime-broker leg.
- Vault capital (deposited stablecoins and any strategy positions held by the vault) is custodied via 3-of-5 MPC signing across independent co-signers. No externally-owned account holds protocol funds at any layer. Signing keys are held in tamper-resistant hardware key management.
- User-held tokens live in the user's own wallet from mint to redemption. The interface signs through the user's wallet and never holds, freezes, or accesses balances beyond what is public on-chain.
The property statement is straightforward. There is no path from any single key compromise to user-fund loss. To remove tokens from the system requires cooperation across the multi-sig threshold and the timelock. To remove vault funds requires cooperation across the MPC threshold. To remove user-held tokens requires the user's own private key.
6. Trade execution: RFQ via broker hedge
Trade execution uses a request-for-quote model with back-to-back hedging at the broker leg.
On a buy, the user enters size and slippage tolerance in the interface. The interface requests a quote from the issuance layer. The issuance layer prices the trade against current broker liquidity, adds the protocol fee, and returns a quote firm for eight seconds. If the user signs within the firmness window, the issuance layer executes the corresponding hedge at the prime broker before confirming the mint on-chain. The user receives the token in the same transaction as the stablecoin debit.
On a sell, the flow is symmetric: the user signs a burn against a quote, the issuance layer unwinds the broker leg, and the stablecoin lands in the user's wallet.
Quote firmness has a cost. The issuance layer warehouses gap risk during the eight-second window. This is acceptable at current size and intentionally bounded. As external market makers come online to fill the RFQ, the firmness window can widen and the warehoused-risk responsibility shifts to the market makers.
Off-hours behaviour
- Crypto. 24/7 execution. Fills are real-time at all hours.
- FX. Markets close from Friday 17:00 ET through Sunday 17:00 ET. Orders during that window queue and fire at market open.
- Equities, ETFs, commodities. Markets close overnight. Orders queue and fire at the next session open.
The interface displays the queue state explicitly. Nothing executes against a stale price.
7. Order types and the keeper
GM Markets supports a market order type and six resting types. Market orders execute against the firm RFQ quote at signing time. Resting orders are triggered by an in-house keeper service.
- Limit. Buy at or below a target price. Stays open until filled, cancelled, or expired.
- Stop. Buy when the market price crosses a trigger level, used for breakouts.
- TP/SL. A market BUY with optional take-profit and/or stop-loss SELL triggers attached. Entry and triggers are committed in the same ticket. Side is locked to buy; the entered prices are future sell triggers, not the entry. If both triggers are set, whichever fires first cancels the other.
- Trail. A stop trigger that follows the price by a configurable distance, locking in unrealized gains as the price advances.
- TWAP. Slices a parent order into evenly-spaced child fills over a configurable duration.
The keeper is operated in-house and runs off-chain. On-chain automation services (oracle-driven keepers, decentralized automation networks) were considered and rejected on two grounds. Per-fire cost is an order of magnitude higher than off-chain execution. Median latency is an order of magnitude worse on stop-style triggers, where slippage is the customer's loss.
Failure mode. If the keeper goes offline, resting orders pause and user-signed market fills continue uninterrupted. No order is auto-cancelled on keeper downtime.
8. Vault framework
Vaults split into two role categories.
Issuer vaults
Issuer vaults originate the underlying cash flows directly. The protocol or a partnered originator deploys deposits into a real-world cash-flow stream (for example, short-duration receivables) and the resulting yield accrues continuously into the vault token's net asset value (NAV). Issuer vaults are not strategy-dependent; risk is the credit and operational risk of the originated asset class itself.
Managed vaults: six strategy subtypes
- Lending. Manager lends vault assets to whitelisted borrowers and earns interest. Yield-accrual; principal exposure is borrower default within the curator's whitelist.
- Delta-neutral. Manager runs basis trades or funding-rate captures. Returns are uncorrelated with spot direction but exposed to basis dislocation and funding inversion. Drawdown risk is real.
- Market-neutral. Manager runs spread or pair trades. Drawdown if spreads dislocate. Not capital-guaranteed.
- Trading. Discretionary or systematic directional strategies. Variable returns, explicit drawdown risk, can produce negative returns over any window. Not capital-guaranteed.
- Looping. Manager loops permissioned tokenized products through DeFi to wrap permissioned yield as permissionless DeFi exposure. Drawdown risk on liquidation cascades and unwind cost.
- RWA. Manager wraps a public real-world asset (such as short-duration treasuries or public credit ETFs) and passes through yield. Yield-accrual; principal exposure is to the wrapped instrument's credit and price.
Naming convention
Vault tokens are named by issuer or manager with a "g" prefix (for example gOpal, gHelix, gMev). Vault tokens are never named after the underlying platform or asset.
Buy and sell mechanics
- Buy. Buy mints the vault token in the same transaction as the deposit. There is no trading fee.
- Sell. Sell queues a redemption at NAV-of-settlement (the NAV at the time the redemption settles, not the NAV at the time of request). The redemption window varies by subtype and is shown on each vault detail page.
Fee defaults by subtype
- Trading: 2% management, 20% performance.
- Issuer: 1% management, 0% performance.
- Lending: 0% management, 10% performance.
- Delta-neutral, market-neutral, looping: 0% management, 20% performance.
- RWA: 0% management, 10% performance.
- Protocol-managed (gLP): 0% management, 10% performance.
Manager-led vaults split fee revenue 70% manager / 30% protocol. Protocol-managed vaults retain 100% to the protocol.
Risk framing
Active-trading subtypes (delta-neutral, market-neutral, trading, looping) carry explicit drawdown language in vault detail pages, including historical worst drawdown and a plain-English description of how the strategy can lose. Yield-accrual subtypes (lending, RWA) and issuer vaults use standard yield-accrual framing.
9. Pricing
GM Markets charges a single trading fee per transaction, applied symmetrically on mint and redeem. The fee is volume-tiered against the wallet's trailing 14-day spot volume.
- VIP 1 (base): 0.20% per transaction.
- VIP 2 (≥ $100K 14-day volume): 0.17%.
- VIP 3 (≥ $1M): 0.15%.
- VIP 4 (≥ $10M): 0.12%.
- VIP 5 (≥ $50M): 0.10%.
Tier assignment is automatic and refreshed continuously against rolling volume. Network gas is paid by the user in the chain's native asset and optimised by batching where possible.
Three commitments accompany the fee schedule. No payment for order flow: GM Markets does not accept or pay rebates to other venues. No proprietary trading against users: the protocol does not run an internal trading desk. No third-party rebate retention: any rebate received from external counterparties flows back to users. Vault deposits and redemptions carry no trading fee.
10. Verification layer
Three independent verification paths are available to any user. Each requires no trust in a GM Markets API.
Reserve attestations
An independent attestation provider publishes a reserve attestation on a regular cadence. Each attestation is signed using EIP-712 typed data, published on-chain, and mirrored to off-chain content storage. The signing public key is published. Anyone can pull an attestation, verify the signature locally, and confirm the reserve figures without trusting any GM Markets-operated endpoint.
Daily proof of solvency
The protocol publishes a daily Merkle sum tree root on-chain. An open-source command-line tool produces an inclusion proof for any given balance and verifies it against the on-chain root. A user can confirm their own balance is included in the supply without revealing it to anyone, and an external observer can verify that total claimed supply equals total proven supply.
Live transparency dashboard
A reading surface that pulls reserve figures, mint and burn events, and audit results directly from the contracts. The reserve ratio updates as the chain advances. The dashboard is a convenience layer over data that is independently retrievable from the chain.
The combination is intentional. The attestation handles off-chain underlying. The Merkle proof handles on-chain supply. The dashboard makes both legible without becoming the source of truth for either.
11. Smart contract design and safety
All production contracts share one codebase across the GM Markets and partnered protocols, allowing a single audit pass to apply to the entire surface. Production contracts deploy on Ethereum, Base, and Arbitrum.
Audit posture
Every production contract is reviewed by at least two independent smart-contract security firms before deployment. Engagement coverage spans formal audit, fuzz testing, and economic-property review. Audit reports are published before public launch.
Reentrancy hardening
Every state-changing function is wrapped with reentrancy guards. Checks-Effects-Interactions ordering is enforced in continuous integration; a violation fails the build.
Standards conformance
Tokens implement ERC-20 with EIP-2612 permit support for gasless approvals. Reserve attestations and proof-of-solvency proofs use EIP-712 typed data signing.
Bug bounty
A continuous self-managed bounty covers smart contracts, custody infrastructure, and the web interface. The maximum payout is $250,000 per critical finding, capped at 10% of funds at risk. High and Medium severities pay $50,000 and $10,000 respectively. Disclosure is via a dedicated security mailbox; safe harbour rules and scope are published with the bounty.
12. Governance and emergency controls
Three controls govern protocol changes and emergency response.
- Multi-sig ownership. A 5-of-9 multi-sig owns the smart contracts. All administrative changes flow through the multi-sig. There is no admin-key override path.
- Timelock. Every administrative change is queued on-chain behind a 48-hour timelock. Users have 48 hours to review and exit before any change takes effect. The timelock applies to fee changes, parameter changes, and contract upgrades.
- Emergency pause. A 7-signer emergency quorum can pause contracts unilaterally; any one of the seven can trigger a pause. Unpausing requires the full 7-of-7 quorum plus a 24-hour timelock. The pause scope is surgical: a single vault, a single tokenized asset, or the entire protocol can be paused independently.
Continuous monitoring
Production contracts and signing infrastructure are monitored in real time. Anomaly detectors escalate via on-call rotation. Auto-pause can fire within 60 seconds of a credible alert.
Signer rotation
The signer rotation policy is in counsel review and will be published before public launch. The rotation cadence, replacement process, and disclosure rules are not yet finalised.
13. Continuity and wind-down
The continuity model addresses three failure modes: operator insolvency, regulatory revocation, and a quorum vote to wind down.
The wind-down trigger is one of: an operator insolvency event, regulatory revocation of the issuer's operating permissions, or a 9-of-9 quorum vote.
On trigger, two transitions occur. First, the MPC quorum transitions to a redemption-only signing policy. Vaults can no longer accept new deposits or rotate strategy positions; they can only honor redemptions. Second, the independent collateral agent is empowered to administer claims directly from the isolated estate, paying redemptions to token holders without operating-entity intermediation.
Operating reserve
An 18-month operating reserve is maintained off-balance-sheet to fund continuity operations during a wind-down. This reserve covers signer infrastructure, custody operator fees, and the collateral agent's administration cost.
Interface unavailability
The interface and the protocol are independent. If gm.markets is unavailable for any reason, tokens remain valid on-chain and redemption proceeds through the issuance layer directly under the published continuity protocol. Users with their own RPC access can interact with the contracts without the GM Markets domain.
Incident communication
A 24-hour public acknowledgement and a 48-hour structured incident report are committed for any continuity event.
14. Limitations and open problems
Several gaps are known and stated explicitly.
- Formal verification. The smart-contract suite has not been formally verified. Audit coverage is independent and multi-firm, but formal proof of safety properties is in scope and not yet done.
- Independent infrastructure pen-test. The keeper, monitoring, and signing infrastructure have not been independently penetration-tested by an external red team. This is in scope and not yet done.
- SOC 2 Type II. SOC 2 Type II certification is in progress and not yet complete.
- Signer rotation. The signer rotation policy is in counsel review.
- Cross-chain assumptions. Tokens deploy on Ethereum, Base, and Arbitrum. Cross-chain message-passing is performed via standard bridge infrastructure; the bridge's trust assumptions are inherited and not amplified.
- Oracle dependency. Price oracles for resting-order triggers depend on a single first-party feed integration. Multi-feed redundancy is on the roadmap.
- RFQ firmness window. The 8-second quote firmness window is an ergonomics-versus-execution-quality tradeoff. At higher volume, the warehoused gap risk during the firmness window may justify a shorter window or a different settlement model. This will be revisited.
15. References
Standards
- ERC-20 Token Standard.
- EIP-2612 Permit Extension for ERC-20 Signed Approvals.
- EIP-712 Typed Structured Data Hashing and Signing.
Architectural references
- Lido staking protocol design (proof-of-stake validator separation pattern).
Live surfaces
- Transparency: live reserve, supply, and ratio figures.
- Proof of reserves: attestation archive and verification tools.
- Audits & security: independent security reviews of the smart contracts.
- Bug bounty: scope, payouts, and disclosure process.
- Docs: user-facing reference, due diligence questionnaire, and legal summaries.
Cite
GM Markets team. "GM Markets: capital markets on permissionless rails." v1.0, 2026.