Verifiable On-Chain Prop Trading

Introduction: The Verification Crisis in Capital Markets

The modern financial landscape is facing a profound verification crisis, characterized by a widening gap between the execution of financial agreements and the ability to prove their outcomes.

This fracture is most visible in proprietary (prop) trading, a $60 billion industry where aspiring traders seek capital from centralized firms. The industry’s promise that skill will be rewarded with capital is often undermined by an opaque “black box” operational model. In this traditional Web2 paradigm, trader performance and payouts are adjudicated on private servers, shielded from audit. This creates a conflict of interest, as the firm evaluating the trader often benefits financially from their failure.

While Decentralized Finance (DeFi) promised a solution through transparency, it has historically failed to match the speed and complex risk modeling required for professional trading. Consequently, traders have remained stuck between high-performance but opaque centralized firms and transparent but slow on-chain protocols.

This report analyzes a solution to this dichotomy: the integration of Carrotfunding.io with the Oasis Network’s Runtime Off-Chain Logic (ROFL).

By deploying a verification layer anchored in Trusted Execution Environments (TEEs), this architecture allows for “trustless auditing.” It combines off-chain speed with on-chain immutability. Supported by rethink.finance for capital management and gTrade for execution, this system represents a shift from “Don’t be evil” (trust us) to “Can’t be evil” (cryptographic proof).

The Pathology of Centralized Proprietary Trading

To fully appreciate the technical necessity of the ROFL integration, one must first rigorously diagnose the pathology of the incumbent system. The traditional proprietary trading firm operates on a model that is fundamentally misaligned with its user base, creating a “Principal-Agent” problem of significant magnitude.

The Black Box Evaluation Engine

At the core of every prop trading firm is the “Evaluation Engine.” This is the software logic responsible for monitoring trader activity, calculating real-time equity, enforcing drawdown limits (e.g., “trailing max drawdown”), and ultimately approving or denying payout requests. In the Web2 model, this engine resides on private cloud infrastructure (e.g., AWS, Azure) controlled entirely by the firm’s administrators.

The opacity of this engine creates a “trusted setup” where the trader essentially operates within a digital panopticon. They are observed, but they cannot verify the observer’s metrics. Research into trader complaints reveals a systemic pattern of “payout denials” predicated on ambiguous or retroactively applied rules.

The Consistency Rule Exploitation

A primary vector for these denials is the “Consistency Rule.” Firms often mandate that a trader’s most profitable day cannot exceed a certain percentage (e.g., 30%) of their total profit to ensure sustainable strategies. However, in a centralized database, the definition of a “trading day” (e.g., the specific millisecond cutoff for daily candles) can be manipulated to shift profits between days, artificially triggering a violation. Traders have reported rejections where firms cited hidden risk parameters that were not explicitly detailed in the initial Terms of Service.

Failure Mode	Mechanism of Action	Web2 “Solution”	Web3 (ROFL) Solution
Slippage Manipulation	Firm widens spreads artificially in the demo environment to trigger stop-losses.	“Trust us” / User Reviews	Verifiable On-Chain Liquidity (gTrade)
Payout Denial	Firm cites vague “risk breach” or “abusive trading” without evidence.	Legal Action (Costly/Ineffective)	Cryptographic Proof of Compliance
Solvency Risk	Firm uses new signup fees to pay old traders (Ponzi dynamics).	None / Bankruptcy	On-Chain Vault Transparency (Rethink)
Rule Drift	Changing evaluation criteria mid-challenge.	Terms of Service Updates	Immutable Smart Contract Logic

The Conflict of Interest: B-Booking and the Casino Model

The financial viability of many retail prop firms relies on the “B-Book” model. In this arrangement, the firm does not route trader orders to a live liquidity provider. Instead, the firm acts as the counterparty to every trade.

• A-Book: The broker passes the trade to the real market. The broker earns a commission.
• B-Book: The broker keeps the trade internal. If the trader loses money, the broker keeps the deposit. If the trader wins, the broker pays out of their own pocket.

This model creates a perverse incentive structure. A profitable trader is a direct liability to a B-Book firm. Consequently, the firm is financially incentivized to find reasons to disqualify successful traders. This structural insolvency risk was highlighted by the collapse of firms like MyForexFunds, where regulators alleged that the firm used specialized software to disadvantage traders, effectively rigging the game. The lack of verifiable infrastructure meant that these manipulations could persist for years undetected.

The Liquidity Illusion in Tokenization

While blockchain technology offers a theoretical antidote to these opacity issues, early attempts at “tokenizing” trading activities often failed to deliver genuine liquidity. As noted by financial experts in the field, tokenization without a robust legal and technical framework often results in “zombie assets” – tokens that exist on-chain but lack a liquid secondary market or a reliable mechanism for value accrual. The challenge, therefore, is not just to tokenize the trader’s performance, but to integrate it into a standardized, high-velocity liquidity environment that can support billions in volume.

The Carrotfunding.io Integration: Architecture and Implementation

The integration of Carrotfunding with ROFL is not a simple replacement of a backend server; it is a fundamental re-architecture of the prop trading trust model. The implementation is designed to address the specific “trust assumptions” identified in the executive summary.

The Parallel Verification Model (Phase 1)

Carrotfunding is currently deploying a Parallel Verification architecture. In this transitional phase, the platform does not immediately abandon its existing AWS infrastructure but rather augments it with a ROFL-based auditor.

Operational Workflow:

1. Trade Event: A trader executes a trade on the gTrade platform via the Carrot interface.
2. Dual Ingestion:

• Path A (Legacy): The trade data is sent to Carrot’s AWS execution engine.
• Path B (ROFL): The trade data is simultaneously ingested by the ROFL node network.

3. Independent Computation:

• The AWS engine calculates the impact on the trader’s account (e.g., calculating daily P&L).
• The ROFL instance, running inside a TEE, performs the exact same calculation using the same code logic.

4. Attestation & Comparison: The ROFL instance generates a cryptographic proof of its calculation. This proof is submitted on-chain. The system compares the AWS result with the ROFL result.
5. Finality: If the results match, the system proceeds. If there is a discrepancy, the ROFL result acts as the “Supreme Court,” providing a cryptographically verifiable truth that overrides the potentially compromised or erroneous AWS database.

This “Belt and Suspenders” approach mitigates the risk of a sudden migration failure while immediately providing the cryptographic guarantees of the TEE.

The “Trustless AWS” Paradigm

The industry has begun to refer to this architecture as “Trustless AWS”. It offers the developer experience of a centralized cloud (deploying Docker containers, running complex logic) but with the security properties of a blockchain.

Technical Comparison of Compute Models:

Feature	AWS (Centralized)	Ethereum (On-Chain)	Oasis ROFL (TEE)
Logic Visibility	Private (Opaque)	Public (Transparent)	Private (Verifiable)
Computational Cost	Low	Extremely High	Medium (Attestation overhead)
Latency	<100ms	12s (Block Time)	Near Native + Verification
Data Access	Full Internet	Oracle Dependent	Secure Internet Access
Tamper Resistance	None (Admin Access)	High (Consensus)	High (Hardware Enforced)

Proxy-Based Frontend Hosting

A significant recent upgrade to ROFL, utilized by Carrot, is the support for Proxy-Based Frontend Hosting. In a typical “Decentralized” App (dApp), the smart contracts are on-chain, but the website (the frontend) is hosted on a centralized server (e.g., Vercel or AWS S3). This creates a censorship vector; if the AWS account is banned, the UI goes down.

ROFL allows Carrot to host the frontend inside the TEE.

• Automatic TLS: The ROFL node can automatically provision TLS certificates using a built-in ACME client (interacting with Let’s Encrypt) entirely inside the enclave.
• End-to-End Security: This ensures that when a user connects to app.carrotfunding.io, the SSL connection is terminated inside the TEE. The node operator sees only encrypted traffic. This protects user privacy (IP addresses, login patterns) from the infrastructure provider itself.

Secret Management and Proprietary IP

One of the key requirements for a competitive prop firm is the ability to protect its internal risk algorithms. If Carrot’s specific formula for calculating “risk of ruin” were public, traders could game it.

ROFL allows Carrot to keep these algorithms private. The code runs inside the enclave. The hash of the code is public (for verification), but the source code itself does not need to be revealed to the public or the node operator. This allows Carrot to maintain its “Secret Sauce” (IP) while proving to the user that the sauce is being applied consistently and fairly.

The Capital Layer: Rethink Finance and On-Chain Investment Vehicles

The verifiability of the trading rules via ROFL is only half of the equation. The other half is the safety of the capital. Carrotfunding leverages rethink.finance to manage the underlying liquidity.

The Principal-Agent Problem in Asset Management

Rethink Finance was built to address the $20 billion in losses attributed to the Principal-Agent problem in 2022 alone. This economic theory describes the conflict where an agent (fund manager) is motivated to act in their own own interest rather than that of the principal (investor).

On-Chain Investment Vehicles (OIVs)

Rethink Finance utilizes a structure known as the On-Chain Investment Vehicle (OIV). Unlike a traditional bank account or a multisig wallet, an OIV is a smart contract system that automates the role of the fund administrator.

• Peer-to-Contract: Investors deposit funds into the OIV smart contract, not to a person.
• NAV Calculation: The protocol creates a “fresh, robust approach” to Net Asset Value (NAV) calculation. This allows for the real-time pricing of the fund’s shares based on the underlying assets.
• Permissioning: The OIV allows Carrotfunding (the manager) to trade the capital but not to withdraw it. The withdrawal logic is hard-coded to respect the profit-share rules defined in the contract.

Institutional Grade Infrastructure

Rethink Finance’s architecture is explicitly designed for institutional use cases, offering a higher degree of granularity than retail-focused protocols like Enzyme or dHEDGE.

• Protocol Agnostic: Unlike competitors that are limited to specific DeFi protocols, Rethink supports integration with all EVM networks and token standards, allowing Carrot to diversify its treasury across various yield-bearing assets.
• Audit History: The protocol has undergone rigorous security audits, including by AuditOne, achieving a 97% security score. This provides the necessary assurance for large capital allocators (LPs) to deposit into Carrot’s funding pools.

Gamification and Performance

Rethink Finance also integrates gamification mechanics into the OIV structure. Research conducted by partner universities indicated that gamification (leaderboards, badges) improved the performance of Gen Z traders by an average of 42%. Carrot leverages this infrastructure to create verifiable trader leaderboards. Because the data feeding these leaderboards comes from the ROFL-verified engine, the rankings are cheat-proof, creating a genuine “Meritocracy of Trading.”

The Execution Layer: gTrade (Gains Network)

While ROFL adjudicates the rules and Rethink secures the capital, the actual execution of trades occurs on gTrade, a product of the Gains Network.

Synthetic Architecture and Liquidity Efficiency

gTrade differs fundamentally from traditional Order Book (CLOB) or Automated Market Maker (AMM) exchanges. It utilizes a synthetic asset architecture.

• No Order Book: Trades are not matched peer-to-peer.
• No Liquidity Pools per Pair: There is no “BTC/USDT” pool. Instead, there is a single gDAI Vault.
• Mechanism: When a trader opens a long position on BTC, they are essentially betting against the gDAI Vault. If the trader wins, the vault pays them. If the trader loses, their collateral remains in the vault.

This architecture allows for extreme capital efficiency. gTrade can offer up to 150x leverage on crypto and 1000x on forex because it does not need to hold the underlying asset. For Carrotfunding, this is crucial. It means they can offer their funded traders access to a massive range of markets (Stocks, Forex, Crypto) without needing to fracture their liquidity across hundreds of different pools.

Arbitrum and Cost Reduction

gTrade operates on Arbitrum (and Polygon), capitalizing on Layer 2 scaling to reduce gas fees.

• Off-Chain Matching / On-Chain Settlement: gTrade processes orders off-chain to minimize latency but settles everything on-chain. This aligns perfectly with the ROFL philosophy.
• Consolidation: By consolidating volume on Arbitrum, gTrade has aimed to capture billions in volume. Carrotfunding piggybacks on this deep liquidity, ensuring that its traders do not face significant slippage, even when trading with large funded account sizes.

The GNS Ecosystem

The ecosystem is powered by the GNS token and GNS NFTs.

• Deflationary Mechanism: A portion of trading fees is used to burn GNS, aligning the incentives of the platform with the token holders.
• NFT Boosts: Holding GNS NFTs provides spread reductions and staking boosts. Carrotfunding can potentially utilize these NFTs within its treasury to optimize trading conditions for its high-tier traders.

Security Deep Dive: Threat Modeling and Defense

The integration of TEEs introduces a new threat model compared to pure blockchain applications. A rigorous security analysis is required to justify the trust placed in the ROFL layer.

Side-Channel Attacks (Spectre/Meltdown)

The primary criticism of SGX/TDX technology is the history of side-channel attacks, where a malicious host analyzes power consumption or memory access patterns to infer data inside the enclave.

• Oasis Mitigation: The ROFL framework enforces the use of the latest microcode patches from Intel. Nodes that do not update their TEE trusted computing base (TCB) are rejected by the Sapphire registry during attestation.
• Data Obliviousness: Developers are encouraged to write “data-oblivious” code – algorithms that perform the same sequence of memory operations regardless of the input data – to thwart access pattern analysis.

Oracle Manipulation

Since the ROFL enclave fetches market data from external APIs (to verify gTrade prices), it is susceptible to oracle manipulation.

• Defense: The TEE can establish TLS connections to multiple independent data providers (e.g., Binance, Coinbase, Kraken) simultaneously. It can then compute a median price inside the enclave before using it for evaluation. This makes the price feed far more robust than a single on-chain oracle update, which might be delayed by network congestion.

Key Leakage

If the private key signing the attestations is leaked, the entire system collapses.

• Defense: Oasis Sapphire uses a decentralized key management system where the master key is sharded across multiple nodes. No single node ever possesses the full key. The keys used by the ROFL app are derived ephemerally and exist only within the volatile memory of the enclave. If the enclave is restarted or tampered with, the keys are lost/wiped.

Verification of the Verifier

Who watches the watchmen? The oasis rofl build –verify command allows any user to audit the system.

• Reproducible Builds: A user can download the Carrot source code, compile it locally using the deterministic build environment provided by Oasis, and obtain the MRENCLAVE hash.
• On-Chain Check: They can then query the Sapphire blockchain to see if the hash they generated matches the hash registered by the active Carrot nodes. If they match, it is mathematically certain that the code on GitHub is the code running on the server.

Future Roadmap: From Prop Trading to Autonomous Agents

The integration of ROFL is not the endpoint but the foundation for a broader evolution of the platform.

Full Decentralization (Phase 2)

The long-term goal is to retire the AWS infrastructure entirely. Once the ROFL layer proves its stability and the fleet of node operators grows sufficiently large to guarantee 99.99% uptime, Carrot will transition to a ROFL-First architecture. In this state, the ROFL nodes will be the only entity authorized to instruct the Rethink vaults to release funds.

AI and Autonomous Trading Agents

The most significant expansion vector lies in AI Agents. The architecture built for Carrot – ingesting market data, processing it through private logic, and executing trades – is identical to the architecture required for autonomous AI hedge funds.

• Private Weights: An AI researcher can deploy a trading bot with a proprietary machine learning model (e.g., a Transformer model trained on niche data). The model weights are encrypted and loaded into the ROFL TEE.
• Public Performance: The bot trades on gTrade. The ROFL attestation proves its P&L history without revealing the model’s inner workings (the “weights”).
• Capital Formation: Based on this verified track record, the agent can attract capital from the Rethink Finance vaults.

This enables a new marketplace of “Verifiable Intelligence,” where AI agents compete for capital in a trustless environment, protected by the privacy guarantees of Oasis and the settlement assurances of Arbitrum.

Decentralized Identity (DID) Integration

Future iterations may integrate Decentralized Identity (DID) standards. ROFL can process sensitive personal data (KYC documents) inside the enclave to verify a trader’s identity (ensuring they aren’t a banned individual or a bot) without ever exposing that data to Carrotfunding’s team or the public chain. This resolves the tension between regulatory compliance and user privacy.

Conclusion

The integration of Carrotfunding.io with Oasis ROFL represents a seminal moment in the maturation of decentralized finance. It effectively closes the “trust gap” that has historically plagued the proprietary trading industry. By replacing the opaque, conflicted “black box” of Web2 evaluation engines with the transparent, cryptographically verifiable “glass vault” of TEEs, Carrotfunding has engineered a system that aligns the incentives of traders, capital providers, and the platform itself.

This architecture, supported by the robust capital vaults of rethink.finance and the efficient execution of gTrade, offers a blueprint for the next generation of financial applications. It demonstrates that the future of finance is not merely about moving assets on a ledger, but about verifying the computational logic that governs those assets. As the platform evolves toward full decentralization and the integration of autonomous AI agents, it stands poised to redefine the standards of transparency, security, and efficiency in the global digital asset market.

Appendix A: Comparative Latency and Cost Analysis

To illustrate the efficiency gains, we compare the cost and latency profiles of executing a standard “Drawdown Check” on a user’s portfolio.

Metric	On-Chain (Arbitrum)	ROFL (Oasis TEE)	AWS Lambda
Execution Cost	~$0.10 – $0.50 (Gas)	< $0.001 (Compute Rent)	< $0.00001
Latency	~250ms (Block time)	~50ms (TEE Overhead)	~10ms
Data Fetch	Oracle Call (Requires Tx)	Direct HTTPS (Internal)	Direct HTTPS
Privacy	Public Visibility	Confidential	Confidential (Trusted)
Throughput	Limited by Block Size	High (Parallel Scaling)	Unlimited

---

Transparency Note: The video introduction to this lesson was generated using NotebookLM. We’ve included this AI-synthesized summary to offer a visual and conversational way to grasp the core concepts. However, for the specific technical details please rely on the written lesson above.