> For the complete documentation index, see [llms.txt](https://docs.carbon.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carbon.inc/about-carbon/the-need-for-carbon.md).
# The Need for Carbon
### TL;DR
* On-chain derivatives represent a small fraction of the global derivatives market. The wedge for the next leg of growth is real-world assets (stocks, FX, indices, commodities).
* Most on-chain attempts at RWAs use **synthetic perps**: perpetual contracts with on-chain mark prices and funding curves. This works for crypto. It drifts on real-world assets.
* The right mechanism for real-world assets is **CFDs**, the instrument TradFi uses for exactly this purpose: $1.5T in daily volume across retail and institutional traders globally.
* CFDs on-chain are hard. They require institutional broker hedging, broker-grade execution rails, and capital pools sized for real-market depth. Smart contracts alone do not solve it.
* Carbon is purpose-built for this. ARFQ-native execution. Broker-hedged CFDs. A community-funded CFD solver vault. Plus 550+ crypto perpetuals on the same rails for the asset class where perps actually fit.
***
### The opportunity is bigger than crypto perps
Crypto perpetuals captured the first wave of on-chain derivatives. Native instruments on native rails, mostly built well, and at this point a meaningful share of crypto trading happens on-chain.
But crypto is one slice of the global derivatives market.
The $1.5T daily CFD market is what gives traders in TradFi exposure to stocks, forex, indices, and commodities. None of it has been served well on-chain.
That's the opportunity.
***
### Why perps drift on real-world assets
Most on-chain attempts at RWAs replicate the price of stocks, commodities, or indices using on-chain oracles and open-interest mechanics borrowed from crypto perps. We call these synthetic perps. They work for crypto. They produce three structural problems on real-world assets.
Perpetual contracts are not broken. They are the right mechanism for 24/7 crypto, where on-chain liquidity is deep and price feeds are robust. They are not the right mechanism for assets whose markets close at 4pm and whose liquidity lives off-chain at regulated brokers.
This is a domain-fit problem, not a defect.
***
### CFDs are the right mechanism for real-world assets
Contracts for difference are the standard instrument TradFi uses to let traders speculate on price movement of real-world assets without owning them. They predate crypto. They handle stocks, forex, indices, and commodities at scale every trading day.
The mechanism is structurally different from perps. A CFD position is hedged 1:1 against the underlying market by the broker on the other side. The trader's mark price is the actual market price during trading hours. Funding rates reflect actual borrowing costs. Liquidity scales with the underlying market, not the local pool.
CFDs are the right answer for RWAs on-chain. The hard part is **building them properly on-chain**.
***
### Why CFDs on-chain are hard
A CFD that delivers real-market behavior needs a counterparty hedging the position 1:1 against the actual market. That means an institutional TradFi broker. Which means four hard pieces have to come together.
**A solver capable of executing trades against broker APIs in real time** while maintaining on-chain settlement guarantees. Quotes have to stream to the trader fast enough to feel native, and fills have to hedge fast enough to keep the broker side delta-neutral.
**A capital pool sized to support broker hedging** at trader scale, not retail-AMM scale. CFD margin requirements at the broker side are real. The pool that funds the solver has to be large enough that it does not become the constraint on trader fill size.
**An execution layer that streams broker-grade quotes on-chain** instead of reconstructing prices from oracle feeds. The whole point is that the trader sees the real market, not an on-chain reconstruction of it.
**Operational integration with the regulated broker side**, transparent enough for permissionless on-chain users. KYC-free for the trader, fully compliant for the hedge counterparty. The two sides have to coexist.
The reason CFDs have not existed on-chain at execution quality serious traders expect is the same reason CFDs took decades to standardize in TradFi: the operational machinery is hard to build, and the rails are different from spot trading.
***
### What Carbon built
Carbon is the on-chain venue purpose-built for this set of problems.
**ARFQ-native execution.** Automated RFQ replaces manual quote requests with continuous executable streaming. Solvers stream live quotes; the trader accepts the best; collateral locks on-chain; the solver hedges. Sub-five-second fills. Broker-grade pricing. Full on-chain settlement.
**Two solver tracks, one venue.** Crypto perpetual flow runs through third-party market-maker solvers competing on price. CFD flow runs through Carbon's proprietary solver, hedged 1:1 through institutional TradFi brokers. Both tracks settle through the same ARFQ rails, into the same on-chain account.
**Community-funded CFD solver vault.** The Carbon Solver Vault (CLP) lets anyone with USDC capitalize the proprietary CFD solver. CFD market-making revenue, traditionally captured by a small set of broker-dealer firms, flows back to vault depositors proportionally to their share.
**One unified account.** A trader holds USDC, opens a long on AAPL, opens a short on BTC, manages both from one account and never leaves their wallet.
This is not bridging crypto and TradFi. It is **building the right rails for each asset class on the same on-chain account**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.carbon.inc/about-carbon/the-need-for-carbon.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.