RobinPerps Whitepaper

1 Project Overview#

RobinPerps brings together a perpetual trading interface, a unified settlement ledger and community participation. Its objective is not simply higher leverage: users should understand capital requirements before opening a position, monitor risk while holding it and review fees and settlement records afterwards.

The three core characteristics are intuitive perpetual trading, USDR settlement, and contribution-driven community incentives. Wallet connectivity supports account access and participation records. The waitlist records interest ahead of staged access.

2 Three Core Characteristics#

2.1 Intuitive Perpetual Trading

The interface combines BTC market data, candlestick charts, margin-based order entry, leverage selection, take-profit and stop-loss settings, and position information. Users specify the margin they intend to allocate; the system derives reference notional and BTC quantity. This separates committed collateral from leveraged exposure.

Position views distinguish entry notional, current reference value, committed margin and unrealized profit or loss. Account trading volume counts filled opening and closing notionals at their execution prices. A price-driven increase in a position's value does not create additional trading volume.

2.2 Unified USDR Settlement

USDR is the internal margin and settlement unit in the current RobinPerps design. Available balances, position margin, trading profit or loss, fees and pending withdrawal amounts are recorded within one accounting framework. This makes account changes easier to interpret and supports reconciliation and withdrawal review.

Using one unit does not remove underlying asset risk. USDR is distinct from USDG, USDT, a proposed governance token and airdrop points.

2.3 Contribution Driven Community Incentives

The community system combines check-ins, social account binding, official-account follow verification and creator submissions. Points, achievement badges and creator scores record participation beyond an initial registration, including continued engagement and original content.

Rewards depend on successful task verification, configuration and published campaign rules.

3 Markets and Price Display#

BTC perpetuals are the primary market in the local trading test. Candlesticks use public Binance BTCUSDT perpetual trade data. The interface also displays mark and index references. Mark prices inform test valuation and risk calculations; candle closes and mark prices can differ.

The server obtains its own reference prices rather than accepting a browser-supplied execution price or profit figure. Invalid or stale data prevents new test fills. The current reference source is not a multi-source oracle and does not demonstrate that an order was executed on an external trading venue.

BTC prices and order notionals may be displayed in USDT reference terms while margin and settlement are recorded in USDR. USD, USDT, USDG and USDR must not be treated as interchangeable assets without explanation.

4 Margin Based Orders and Trading Records#

Users select long or short, enter a margin amount and choose leverage. They can then review estimated notional, BTC quantity, initial margin, trading fee and liquidation price. Market previews use the current reference; limit previews use the entered limit price.

Order notional = initial margin x leverage.

BTC quantity = order notional / reference entry price.

For example, with BTC at a 100,000 USDT reference price, 100 USDR of margin at 10x produces approximately 1,000 USDT of notional and 0.01 BTC. At the current test fee of 0.04% per fill, the opening fee is approximately 0.4 USDR. Available funds must cover margin plus that additional fee. Price movement and quantity precision can change final amounts.

The local test supports market and limit orders, isolated margin, 1x to 100x test leverage, take-profit, stop-loss, cancellation and closing. The test leverage maximum is not a commitment for a future live service or evidence of capital adequacy.

Entry trade notional = filled BTC quantity x executed entry price. It is not recalculated at later market prices.

Total trading volume = the sum of all filled opening and closing notionals. Take-profit, stop-loss and liquidation fills count. Unfilled, cancelled and rejected orders do not. An opening fill of 1,000 USDT followed by a closing fill of 1,100 USDT contributes 2,100 USDT of volume, not 100 USDT.

5 USDR Accounts Conversion and Withdrawal#

5.1 Accounting Boundaries

The ledger separately records available cash, position margin, limit-order reserves, realized and unrealized profit or loss, fees and frozen withdrawals. This prevents the same available balance from being reused. Account volume is calculated from complete persisted fill history, not only the latest rows displayed in the interface.

USDR uses dollar value as its design reference. That reference is not an unconditional promise to exchange USDR for USDT, dollars or another asset at one to one. Redemption capacity depends on actual assets, liquidity, permissions, execution arrangements and applicable terms.

5.2 Conditions for Real Assets

A future real USDG integration must credit verified asset receipts. An ETH integration must separately define the executable conversion route, quote, slippage, costs, risk allocation and assets actually received before crediting USDR. A dollar valuation of ETH must not be presented as stablecoin reserves already obtained.

5.3 Withdrawal and Redemption

The current local USDR workflow freezes a requested amount, applies a 14-day waiting period, requires a manually entered administrator-reviewed payout, and completes only after manual test settlement confirmation. Both approval and maturity are required. Cancellation or rejection releases the frozen amount. If an approved payout is smaller than the amount frozen, the difference returns to the user's available cash rather than becoming platform revenue.

These are local ledger rules, not a contract-enforced real redemption promise. USDR, the existing ETH vault and other contracts require separate withdrawal disclosures. A website countdown or manual approval must not be represented as a restriction enforced by every contract.

6 Equity Fees and Risk Calculation#

Initial margin supports position risk; it is not a fee earned by the platform when a trade opens. In the current isolated-margin test, maintenance requirements, reference prices, profit or loss and fees determine risk handling. Positions can be closed at liquidation thresholds before all initial margin is exhausted.

Trading account equity = available cash + position margin + open-order reserves + unrealized profit or loss.

Margin in use = position margin + open-order reserves. Order reserves include estimated opening fees. Unconverted assets and frozen withdrawals are shown separately rather than included in trading account equity.

The current test records a 0.04% trading fee on each fill, charged separately on opening and closing. Funding and network gas are different items. Changing leverage alone does not change this fee for the same notional order.

Local funding windows are UTC 00:00, 08:00 and 16:00, using a reference funding rate and position notional. Missing historical windows after downtime are not fabricated using the latest rate. This is not an external venue's actual funding transfer.

Insurance funds, portfolio margin, multi-source oracles, partial liquidation and auto-deleveraging remain research topics from the earlier draft. They are not represented as deployed capabilities, funded reserves or loss-coverage guarantees.

7 Community Tasks and Points#

Check-ins, X binding, Discord binding and official X follow verification have separate completion records. Verification must reflect an actual bound identity and task requirements; opening a page is not successful completion. Telegram binding remains Coming soon and is not promoted as an available verification capability.

Current task periods use UTC+0. Completed check-ins, successful social tasks and point credits should have corresponding records, and the same reward must not be claimed twice. One-to-one social binding is an account rule, not proof that one person controls only one wallet.

Abnormal participation and campaign disqualification may be reviewed manually. A dispute about campaign points must not be conflated with asset balances. Historical records, decision evidence and appeal information should be retained.

8 Creators and Mindshare#

Creator submissions must originate from the connected X account and include the official handle @Robin__Perps_. Mentioning the project name alone does not satisfy the current rule. Replies and reposts are not eligible original submissions, and a previously submitted post cannot be submitted again.

The current creator task allows at most one eligible submission per UTC day, with a base task reward of 10 points subject to verification and campaign rules. Creator rankings use weekly periods; lifetime submission totals are not automatically a weekly ranking.

Administrators review submissions by user and assign scores for project-specific Mindshare rankings. Likes, reposts, replies and views can inform evaluation, but refreshing those metrics requires manual confirmation and is not guaranteed to be continuous or real time. Mindshare is an internal contribution measure, not independently verified market-wide share of attention.

9 Achievements and Incentive Boundaries#

Achievements record milestones such as X connection and 3-day, 10-day and 50-day check-in streaks. Eligible, claimed achievements display a completed state. The previous Social Duo achievement has been removed.

Unfinished items, including the OG NFT and Creator Top 100 badge, must be labelled planned or Coming soon. An all-social achievement requiring Telegram must not be presented as fully available before Telegram verification opens.

Points, badges, USDR and a governance token serve different purposes. Points and badges do not guarantee a future token allocation. Holding USDR does not automatically generate interest or investment yield. Any future USDR holding-based point campaign requires separate rules and is not currently treated as active.

10 Architecture and Manual Review#

The existing system includes the website, backend services, database and separate on-chain asset interactions. The backend maintains test execution and USDR accounting. On-chain vault state, internal account balances and community points must be reconciled separately.

Administrators can review creator content, account records, deposit and withdrawal logs, and reports. The waitlist records wallet registration, time and status, with administrator search and CSV export. Registration does not automatically grant trading access or rewards.

Post-opening review, abnormal-participation decisions and refund calculations are handled manually. Review must not rewrite execution history, reset entry prices or remove legitimate profit simply to eliminate a user's gains. Any future administrative risk close should use disclosed rules, proper settlement evidence and complete records.

11 Security Permissions and Risks#

Unified settlement does not remove leverage, volatility, price-source, liquidity or custody risk. The platform controls the internal ledger and manual review process. Vaults that grant administrator withdrawal powers introduce additional permission risk. Wallet access alone does not make the whole system fully non-custodial.

High leverage magnifies the effect of adverse price movement on margin. A liquidation estimate is not a guarantee of maximum loss or final execution price. Downtime, price gaps, latency and invalid data can affect both test and future real execution.

A stable-value accounting objective does not mean reserve assets cannot fall in value, liquidity is always sufficient, or redemption is unconditional under law or contract. Real-asset services require disclosure of counterparties, capital arrangements, permitted asset use and loss-handling procedures.

Sensitive signatures should bind purpose, domain, wallet and time, with replay prevention. Administrative actions require authorization and records. Passing tests is not an independent audit. This document does not claim completed multi-round audits, funded insurance or trustless on-chain execution.

12 Roadmap and Long Term Research#

Near-term work focuses on validating BTC trading, margin entry, USDR accounting, community incentives and manual review, while preparing waitlist access in an independent release branch. Development and release environments remain separate; test balances, data and credentials must not be copied into production.

Real conversion, USDR issuance and redemption, production execution and wider access require separate validation of contracts, reserves, pricing, risk capacity, permissions and applicable requirements. No launch date, principal protection or fixed return is promised here.

Longer-term research topics include Robin Range Liquidity AMM, professional market making, curated vaults, rLP and rPOS receipts, portfolio margin, insurance funds, Guardian roles, timelocks, multisignature governance and cross-chain mechanisms.

ROBIN is a governance and utility token concept under research, separate from USDR. This draft does not confirm its supply, allocation percentages, investor allocation or initial TGE float. Any issuance arrangements require separate project confirmation and disclosure; existing financing, issuance or distribution commitments must not be inferred from this document.

13 Conclusion#

RobinPerps is focused on a clearer perpetual trading experience, unified USDR settlement accounting and sustained recognition of community contribution. Product claims should follow verifiable implementation, while research topics should remain explicitly forward-looking.

Appendix Terminology#