Verifiable On-Chain Prop Trading & the Emergence of Trustless Market Infra: A Case Study

TL;DR

• Prop trading relies on opaque risk engines that traders cannot verify.
• This creates structural incentives for payout denial and abuse.
• Carrotfunding introduces parallel verification with Oasis ROFL to audit AWS-based execution.
• The result is a hybrid architecture that brings verifiable compute, privacy, and trustless settlement to prop trading.

Introduction

Decentralized trading is one of the most popular applications of cryptocurrency technology. Have we become stagnant in our approach? For example, proprietary (prop) trading, despite being a $60 billion industry, faces a verification crisis common in the modern financial landscape.

Aspiring traders seek capital from centralized institutions. However, an opaque “black box” operational model widens the gap between the industry’s assurances that skill earns reward of capital and the reality where proving performance and worthiness is erratic and arbitrary.

The web2 paradigm adjudicates trader performance and rewards on private servers that are not auditable. Moreover, the evaluating firms profit more when traders fail, as it means there is less capital disbursement.

Decentralized finance (DeFi) has blockchain’s built-in transparency to solve the blind spots of the traditional web2 approach. However, adoption has been low over the years because on-chain trading has failed to match the speed and complex solutions that traditional institutional finance (TradFi) offers.

In this post, I will refer to the Carrotfunding case study to examine how it can serve as an example of an emergent trustless market infrastructure. I will first demonstrate the gaps in the incumbent systems, and then show how a framework like Oasis ROFL can elevate the process by bringing decentralization, verifiability, and privacy to the table.

Black Box Evaluation Engine

The evaluation engine is the backbone of any prop trading firm. This software logic monitors trader activity, calculates real-time equity, enforces parameters and limitation criteria, and, finally, approves or denies payout requests. Private cloud infrastructure, like AWS, Azure, etc hosts such a risk engine with its access and management entirely in the firm’s discretion.

Sounds simple and is “trusted”, right? But the traders can never verify the validity of the metrics on which they are observed and evaluated. Let’s now take a look at how ambiguity in rules and retroactively applied rules can result in most payout denials.

Consistency Rule Exploitation

A common practice among firms is that a trader’s most profitable day cannot exceed a certain percentage of their total profit. This creates an untenable bind for traders when centralized databases can arbitrarily change risk parameters and payout criteria without explicitly detailing them beforehand.

B-Book Model

• A-Book is when the broker passes a trade to the market involving live liquidity providers and earns a commission.
• B-Book is when the broker keeps the trade internal, where the firm acts as the counterparty to every trade. The broker here keeps the deposit if the trader loses money, and pays out of pocket if the trader wins.

The B-Book model creates an incentive system where a profitable trader becomes a liability. So, the incentive is on the firm to disqualify traders and disadvantage them, and without a verifiable infrastructure, regulators cannot do much.

Liquidity Illusion in Tokenization

Blockchain technology’s initial solution of tokenizing trader performances is more theoretical than practical. Tokenization of trading activities can lead to an illusion of liquidity unsupported by reality. So, tokenization that lacks a robust legal and technical framework can result in zombie assets — tokens exist on-chain, but there is no genuine liquidity market or a reliable mechanism for value accrual.

Carrotfunding Case Study: Architecture and Implementation

Carrotfunding, even before integrating Oasis ROFL, had already implemented web3 solutions for its prop trading venture. Its on-chain liquidity adopts the Arbitrum’s gTrade solution for trade execution, while utilizing Rethink Finance for on-chain investment vehicles with gamification mechanics and vault transparency for capital safety.

This takes care of the execution layer and the capital layer, but what happens to the verifiable compute and security layer? This is the domain of Oasis ROFL, and deserves a closer look.

Parallel Verification Model (Phase 1)

In this phase, Carrotfunding continues to use AWS infrastructure for its platform and strengthens it with parallel verification with an ROFL-based auditor. The workflow unfolds in five stages.

1. A trader executes a trade on the gTrade platform via the Carrotfunding interface.
2. This bifurcates into two distinct paths: (a) Legacy: The trade data goes to Carrot’s AWS execution engine. (b) ROFL: The data simultaneously goes to the ROFL node network.
3. The computation takes place independently. (a) AWS calculates the impact on the trader’s account, for example, the trader’s daily profit and loss statement. (b) ROFL, running inside a trusted execution environment (TEE), performs the same evaluation using the same code logic.
4. ROFL provides attestation and verifiability through comparison. This is based on the cryptographic proof generated from its calculation and submitted on-chain, where both the AWS and the ROFL results are matched.
5. The finality of the process is provided by ROFL. If the two results match, no problem. If they differ, then ROFL’s result, having cryptographically verifiable proof, is accepted over the AWS result, which might be potentially compromised or based on an erroneous database.

The “Trustless AWS” Paradigm

We can call this architecture “Trustless AWS”. ROFL, often described as a decentralized TEE cloud, enables the best of both worlds in terms of developer experience — the benefits of a centralized cloud, involving deployment of Docker containers and running complex logic, while also having the advantages of the security properties of a blockchain.

A comparison of the computational models will clarify further.

Proxy-Based Frontend Hosting

Carrotfunding utilizes the ROFL primitive called proxy-based frontend hosting. Typically, a decentralized application (dApp)’s smart contract logic is on-chain, but the website, which is the frontend, is still hosted in a centralized cloud provider, for example, AWS. So, if the cloud server goes down, the UI is also down.

With ROFL, Carrotfunding can host the frontend inside the TEE. As a result, the node can automatically provision TLS certificates using a built-in ACME client inside the secure enclave. There is also end-to-end security as a user’s connection via SSL terminates only inside the TEE. This protects user privacy, shielding IP addresses and login patterns from the node operator and infrastructure provider.

Secret Management and Proprietary IP

For any prop trading firm, keeping its internal risk algorithms secret is how it stays competitive. Full transparency of blockchain technology is counterproductive in this regard. The smart privacy feature of Oasis technology ensures that both transparency and confidentiality can co-exist.

So, with the code running inside the TEE, Carrotfunding can keep its algorithms private. Here, the hash of the code is accessible publicly for verification, but the source code remains encrypted, out of public viewing scope, and unrevealed to the node operator.

Security: Threat Model and Defense

Integrating TEE often opens up the question of security, as the SGX/TDX technology can succumb to various vulnerabilities.

• Side-Channel Attacks: This is mitigated in two ways. The ROFL framework ensures that the latest microcode patches from Intel are used. So, any node that is found without a TEE trusted computing base (TCB) update is rejected by Oasis’s confidential runtime on-chain logic, Sapphire’s registry. Also, using “data-oblivious” code helps block pattern analysis of memory access.
• Oracle Manipulation: This is mitigated by simultaneous TLS connections to multiple independent data providers for the price feed, computed inside the enclave for the median price, used to evaluate instead of relying entirely on a single on-chain oracle update.
• Key Leakage: This is mitigated by a decentralized key management system where the master key is sharded across multiple nodes. So no single node ever possesses the full key. Also, ROFL enables ephemeral keys so that they exist only in volatile memory and will be wiped and lost whenever the enclave restarts or if any tampering is ever attempted.

In addition, the adoption of consensus as a verifier by a Byzantine Fault Tolerance (BFT) network like Oasis ensures that all potential gaps in remote attestations of the TEEs are addressed.

The Verifiability X-factor

This is crucial in understanding the role Oasis ROFL plays in upgrading the risk engine of Carrotfunding from what traditional models can provide. Any user can, therefore, audit the system by using the command:

oasis rofl build -verify

• Reproducible builds allow users to download the source code, compile it locally using the deterministic build environment provided by Oasis, and obtain the MRENCLAVE hash.
• Users can then query the Sapphire runtime for an on-chain check if their generated hash matches the one registered by active nodes. If yes, it is the immutable proof that the code on GitHub is the code running on the server.

From Prop Trading to Autonomous Agents (Phase 2)

Integrating Oasis ROFL to verify the AWS risk engine by Carrotfunding is just the stepping stone to a paradigm shift in prop trading. It aims to evolve into a self-sustaining infrastructure that can ultimately replace the AWS system altogether.

This full decentralization mode becomes viable only after there is sufficient stability and enough node operators in place to guarantee 99.99% uptime. With the transition to a ROFL-first architecture, the Carrotfunding platform can then use only ROFL nodes to authorize Rethink Finance’s capital layer for fund release.

The evolution of the platform’s architecture and functionality into autonomous trading agents is also part of the future roadmap. This envisions a marketplace for verifiable intelligence, where the 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) is another key area to explore since ROFL can process sensitive personal data (KYC documents) inside the enclave to verify a trader’s identity and reputation score.

Conclusion

The study suggests that DeFi can hold its own against TradFi, which had a historical monopoly in the prop trading market. Now, there is a live example of how the limitations of web2 finance, where asset management meant opaque computation logic, can be improved with web3’s verification layer to prove the process.

By removing trust assumptions and plugging the trust gap, Carrotfunding has engineered a system that aligns the incentives of traders, capital providers, and the platform itself. We now await the full decentralization and agentic future for on-chain prop trading, redefining the standards of transparency, security, and efficiency for the next-gen trustless digital asset market.

Resources referred:

• Oasis Academy course
• Oasis blog on prop trading and Carrot
• Oasis X article
• Carrotfunding X article
• Oasis blog on ROFL primitive of proxy support for frontend hosting
• Oasis blog on decentralized key management
• Oasis blog on attestation is not enough

Originally published at https://dev.to on January 19, 2026.

Verifiable On-Chain Prop Trading & the Emergence of Trustless Market Infra: A Case Study was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.