> 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 are still a small slice of the global derivatives market. The next leg of growth is real-world assets: stocks, forex, indices, commodities.
* There are two ways to bring real-world markets on-chain, and they serve different traders. **24/7 markets** give always-on, on-chain access. **Hedged execution** gives real market pricing, tracked 1:1 against the underlying.
* Most venues only do the first. Carbon does both: 150+ **24/7 RWA markets** for always-on access, and 250+ **Carbon TradFi** markets hedged 1:1 at regulated TradFi venues for real-market execution.
* The hard part is the hedged side. It needs institutional venue hedging, broker-grade execution rails, and capital pools sized for real-market depth. Smart contracts alone do not solve it. Carbon built it.
* Plus 530+ crypto perpetuals on the same rails, in the same account.
***
### 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.
***
### Two ways to trade real-world markets on-chain
There is no single right answer. There are two mechanisms, and they suit different trades.
**24/7 markets (synthetic, always-on).** Replicate a real-world asset's price on-chain using oracles and open-interest mechanics, the same primitive as crypto perps. The win: the market never closes. You can trade Apple or gold at 2am on a Sunday, with the speed and composability of crypto. The tradeoff: while the underlying exchange is closed, pricing runs on on-chain mechanics, so it can move away from where the real market will reopen. For always-on access, that tradeoff is worth it.
**Carbon TradFi (hedged 1:1).** Hedge each position against the underlying market at a regulated TradFi venue, the way the CFD market has worked in TradFi for decades. The win: the trader's mark price is the real market price during market hours, overnight rates are benchmark-anchored, and liquidity scales with the real market rather than an on-chain pool. The tradeoff: it follows market hours. For real-market execution, that is exactly what you want.
Perpetual contracts are not broken, and neither mechanism is wrong. Perps are purpose-built for 24/7 markets where on-chain pricing works well. Hedged execution is purpose-built for traders who want their fills to track the real market tick for tick. This is a domain-fit choice, not a defect in either tool.
Most venues offer only the 24/7 side. Carbon offers both.
***
### Why the hedged side is hard to build
Anyone can list a synthetic 24/7 market. Delivering real-market, hedged execution on-chain is the hard part, which is why almost no one has. It needs a counterparty hedging each position 1:1 against the actual market, which means an institutional TradFi venue. Four hard pieces have to come together.
**A solver that executes against venue APIs in real time** while maintaining on-chain settlement guarantees. Quotes have to stream fast enough to feel native, and fills have to hedge fast enough to keep the venue side delta-neutral.
**A capital pool sized for real-market hedging** at trader scale, not retail-AMM scale. Margin requirements at the venue 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 venue-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 venue 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 hedged real-market execution has not existed on-chain at the quality serious traders expect is the same reason it 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. TradFi 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 TradFi Solver Vault.** The Carbon Solver Vault (CLP) lets anyone with USDC capitalize the proprietary TradFi solver. TradFi 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.