Technical whitepaper · Version 1.1 · 9 September 2026
Website: lctm.finance · Official X: @LCTM_rh
1. The idea
LTCM provides stock-token trading on Robinhood Chain and RWA token purchases on Ethereum with 0% LTCM platform trading fees. Holder rewards are funded separately from creator fees collected by the project's dev wallet. The platform does not deduct a trading commission to fund those rewards.
The reward funding sequence is creator fees collected by the dev wallet → reviewed reward funding → published funded distribution → holder claims. Collection, conversion where needed, funding and distribution each require actual transactions. A creator fee receipt does not automatically become a holder payment, and token ownership does not guarantee a payment.
LTCM is an independent onchain project. It is not the historical Long-Term Capital Management partnership, and it is not affiliated with that partnership or Robinhood. Its implementation is original software developed from public product behavior and public protocol interfaces. It does not use Marlin's private source code or operating accounts.
This document explains the implemented architecture. Current trading availability is reported by each desk and its verified configuration; publishing this document does not activate a contract, fund a reward, or establish a record of live trading.
2. The two trading desks
| Desk | Network | Payment asset | Implemented order direction |
|---|---|---|---|
| Stock-token desk | Robinhood Chain, chain ID 4663 | USDG | Buy and sell approved stock tokens |
| Ethereum desk | Ethereum, chain ID 1 | USDC | Buy supported gold-backed and RWA-related tokens |
The desks use separate contracts and network balances. The Ethereum desk does not automatically bridge funds, and its current implementation is a purchase flow rather than a general two-way exchange. An RWA-related protocol token is not necessarily a claim on a physical asset; the token's own issuer terms and rights remain relevant.
On the stock desk, the user selects an asset, order direction, amount, and slippage setting. The application obtains a pool quote and displays the desk fee and minimum amount received. When execution is available, the wallet separately confirms any required token allowance and the trade. Connecting a wallet alone does neither.
Stock execution uses approved stock/USDG pools through the fixed router. Ethereum purchases use reviewed, allowed routes from USDC, including routes through WETH where configured. The signed Ethereum order is bound to the reviewed route hash. A different asset, account, network, expired quote, or changed route requires a fresh review.
3. Prices, quotes, and charts
The product distinguishes three kinds of information:
- Market references: stock identities, timestamps, trading-halt information, and reference prices from Robinhood. The reference calculation adjusts the underlying bid/ask midpoint by the token's share multiplier. Stale or halted references are withheld.
- Pool quotes: estimates from actual onchain liquidity for a particular order. The final transaction must satisfy its minimum output and deadline.
- Pool history: recorded prices from a stated pool, shown with their source and time range. Missing trading intervals are not invented, and a chart is not an executable price or a valuation of the issuer's underlying assets.
Robinhood documents the difference between raw underlying-equity prices and multiplier-adjusted token values in its Stock Token API documentation. A historical chart, a reference price, and the amount received from a swap can differ because of liquidity, spreads, fees, price impact, and timing.
4. Trading-desk fees
Both desk implementations charge 0 basis points: 0%. No part of an order is diverted to an LTCM trading-fee treasury.
| Order | LTCM desk fee | Amount used or delivered |
|---|---|---|
| Stock-token buy | 0% | Full USDG input goes into the swap |
| Stock-token sell | 0% | Full USDG swap output goes to the user |
| Ethereum purchase | 0% | Full USDC input goes into the purchase |
For example, a 100 USDG purchase routes the full 100 USDG into the pool. The LTCM platform fee is zero. This does not promise a particular token output: underlying pool fees and price impact affect the swap, and network gas is separate. The sell-side minimum protects the actual output delivered to the user.
The fee is fixed at zero in the reviewed desk implementation. Administrators cannot raise it through a fee-setting function. They retain the documented route, asset and pause permissions. Transactions can still spend network gas when reverted. Required allowance transactions are separate wallet actions and can have their own gas cost.
5. Creator fees and reward funding
The creator-fee wallet belongs to the client. Creator fees are a separate token/launchpad mechanism; they are not commissions charged by the LTCM stock or Ethereum desks. The website does not have access to that wallet's private key and does not silently sweep its funds.
The authorized wallet owner must approve any required conversion into the reward token and the funding/publication transactions. The funded distributor then supports holder claims. Until the client supplies the public wallet and token identities and actual funding occurs, the website must not report creator receipts or distributions as live activity.
The repository also contains a PONS launch-wrapper/receiver implementation and a protocol-owned liquidity book. Those components are separate from the zero-fee trading desks and from direct dev-wallet-funded distributions. They require their own explicit deployment, economics and capital decisions; their presence in the source does not make them part of an active distribution cycle.
6. The protocol-owned liquidity book
The liquidity book holds the protocol's own concentrated-liquidity positions. Authorized operators can convert funds through the fixed routes, acquire approved stock tokens, mint or increase positions, collect earned fees, and unwind positions for reinvestment.
Principal remains protocol-owned. On an unwind, the contract first checkpoints earned fees, applies the fee allocation to those earnings, and returns the position principal to the book. Principal is not distributed as holder income. The implementation has no user-deposit or redemption interface and no general external principal-withdrawal, NFT-transfer, or arbitrary-call function.
Concentrated liquidity earns fees only under the conditions of its pool and selected range; an out-of-range position may stop earning. Operators must choose sizes, assets, ranges, minimum outputs, and deadlines. Those choices can lose value. A slippage minimum limits execution behavior; it does not establish a fair market price. See Uniswap's concentrated-liquidity explanation.
7. Funded holder rewards
If the separate liquidity-book module is deployed and funded, its actual earned LP fees are allocated 80% to the rewards treasury and 20% to the desk treasury. This optional LP allocation is not a trading-platform commission and is not the rule for direct creator-fee-funded distributions. The split is applied to each token received from a position. It is not 80% of trading volume, not 80% of principal, and not a promised annual yield.
The rewards treasury can receive multiple assets. Conversion into the distributor's single reward token is a separate reviewed operation. The book's mixed-token rewards treasury must therefore not be confused with the reward distributor itself.
A distribution follows five steps:
- Select a finalized snapshot block and publish the eligibility/exclusion policy for that distribution.
- Reconstruct and verify balances at that block, then calculate each eligible holder's allocation from the funded budget.
- Build a Merkle distribution manifest containing the snapshot, allocations, and proofs.
- Publish the next epoch's immutable root and transfer its full declared funding in one transaction.
- Submit claims. A holder or a relayer can submit a valid proof, but payment always goes to the proven holder address.
For a pro-rata distribution, a holder's share is their eligible snapshot balance divided by the total eligible balance, multiplied by the distribution budget, subject to integer rounding. Transfers after the snapshot do not change that epoch's allocation.
Each proof is bound to the chain, distributor, epoch, account, and allocation. The expected-epoch check prevents an outdated publication plan from funding the wrong epoch. Published roots cannot be replaced; the distributor has no owner-withdrawal or epoch-expiry function.
The publisher remains responsible for accurate snapshots, exclusions, allocations, and the total. A Merkle proof verifies inclusion in a published tree; it does not independently prove that the publisher calculated every holder's entitlement correctly. Distributions depend on actual funding and publication, with no guaranteed daily amount or fixed return.
8. Public records
The public register is a read-only view of connected, verified liquidity and distribution contracts. Before reporting records, the backend checks the network, runtime code hashes, ownership, canonical dependencies, position custody, and reward-token identity at a safe block.
Position and epoch records are paginated. Recorded fee totals are checkpointed token amounts, not necessarily current uncollected fees or a dollar-denominated portfolio valuation. Missing contract configuration is shown as unconnected data rather than fabricated zero activity. The register never asks for a wallet signature.
9. Control and operating responsibilities
LTCM's operating model includes trusted administrators and authorized operators. Contract owners control the permissions supported by each contract, including approved assets, operators, or routes and pause controls. Operators make the liquidity-management decisions described above. The reward publisher determines and verifies distribution manifests under the disclosed policy.
The keeper prepares and executes reviewed maintenance calls. Its execution path requires explicit enablement, the correct signer, gas budgets, an exclusive job lock, a durable pre-broadcast journal, sequential confirmation, and reconciliation after interrupted or uncertain broadcasts. These controls reduce operational mistakes; they do not remove administrator trust or market risk.
Signing keys belong in the operator's controlled signing environment. They are not part of the public website or its browser bundle. Data-service credentials belong in server-side encrypted settings. Client handover must include ownership of the domain, hosting, provider accounts, login application, contract administration, monitoring, and recovery procedures.
10. Availability and execution safeguards
Publishing the website is separate from enabling funded execution. Before an order can be submitted, the implementation verifies the configured network and owned contract identities, runtime code, expected administrator, canonical dependencies, zero-fee configuration, and availability controls.
If those checks fail, the desk withholds execution. Public data may remain readable while trading is unavailable. Email login is available only when an owned login application and its production origins are configured and explicitly enabled. Connecting a wallet never requests its recovery phrase.
There is no implemented user-deposit vault, automatic cross-chain bridge, guaranteed redemption of the LTCM token for book principal, or independently verified fully autonomous investment strategy in this release.
11. Risks and verification limits
Material risks include token-price losses, liquidity and range risk, stablecoin and issuer risk, upstream protocol changes, data outages, transaction ordering, contract defects, and compromised or mistaken administrators and operators. Fees can be zero, and protocol assets can lose value even when fee collection works as designed.
Automated tests, local integration exercises, and historical chain-fork simulations establish specific tested behavior. They do not prove future profitability, uninterrupted availability, security under every condition, or successful settlement on a currently funded production deployment. The client handover report records the latest test results and remaining activation requirements separately. No independent external security audit is represented by this whitepaper.
12. Implementation references
The implementation is organized around LTCMDesk, LTCMRwaDesk, LTCMPonsFactory, LTCMFeeReceiver, LTCMLiquidityBook, and LTCMRewards, together with quote/data services, wallet interfaces, and operator tools.
The deployed service reports current availability through the stock-desk configuration and Ethereum-desk configuration. Official communications are linked from @LCTM_rh. A token name or ticker alone is not a contract identity.
Source trace: architecture and fee descriptions checked against the original protocol source, engine services, operator documentation, and website routes on 9 September 2026. External reference definitions are linked inline. Current funding, deployments, account ownership, and release-test outcomes belong to the separate dated handover report.