The problem Conduit solves

Problem

The world needs $3+ trillion per year in new climate infrastructure investment to meet its 2030 targets — yet almost none of that capital is accessible to everyday investors, and private markets are chronically undersupplied. Analysts at BCG project that tokenizing real-world assets could unlock $16 trillion in on-chain value by 2030, but today only ~$24 billion has made it on-chain. Why such a massive gap?

Because the industry is currently paralyzed by extreme illiquidity and the "Oracle Problem". Underwriting these asset-heavy projects requires six months of opaque due diligence. And once invested, these funds are locked up for years with virtually no secondary market. Until verifiable evidence of real-world output is provided — along with an efficient way of entering and exiting these markets — trillions of dollars will continue to be held on the sidelines.

The Solution

Conduit is an autonomous clearinghouse solution that unlocks a massive new financial primitive by turning static and illiquid climate infrastructure into a dynamic, highly liquid financial instrument.

Tokenization of the physical asset is completed on the compliance-forward ADI Chain, meeting strict institutional custody requirements (like FATF and ADGM regulations) to safely bring on massive institutional capital. Then, using QuickNode, cryptographically verifiable telemetry data is streamed directly from the hardware into Conduit.

For the trading piece, Conduit utilizes Hedera's high-volume network to democratize access for traders. They can trade manually through our clean GUI — akin to Robinhood — or deploy complex options through our Intent-Based AI Copilot using only natural language. These trades trigger smart contracts on Hedera that utilize Hedera's Schedule Service to automatically settle derivatives based on the physical asset's real-time yield data.

By combing ADI's compliance with Hedera's volume capabilities, Conduit allows infrastructure investing to be radically faster, infinitely more liquid, and cryptographically safe for everyone.

Challenges we ran into

Challenges We Faced

We needed to integrate four systems into one cohesive workflow. Conduit integrates ADI Chain, Hedera, QuickNode, and an AI copilot using 0G. Most of our toughest bugs were in the boundaries between these systems, not in any one particular one.

1. Getting Scheduled Settlement to Actually Execute

The problem: Options seemed to be successfully written. The UI reflected it. Events were emitted. But scheduled settlements didn't run.

We discovered three major, compounding root causes. The user's wallet, not the contract, was being charged execution fees. If the user's state changed, it would fail. Authorization failure was not being checked, so it looked like it worked, but it didn't. The contract didn't have guaranteed funds to execute on-chain.

How we fixed it: The contract itself is set to pay for scheduled transactions. Authorization failure now triggers hard reverts, so it can't silently fail. Funding and balance checking functions were added to the contract, so it can be funded before any option is written.

2. Keeping Strike Prices and Oracle Prices in Sync

The problem: Options write successfully, but then settlement is incorrect. The contract references the user's strike price and oracle prices. The contract references these prices in comparison to one another during settlement. However, strike prices and oracle prices are in different units, making it difficult to reconcile them.

How we fixed it: The AI copilot does not directly use the user's entered strike as the contract strike anymore. Instead, at submission time, it now retrieves the current asset price from our SolarTick backend and uses this as the strike value, reverting to the user's entered value only if it was unable to connect to our backend and logging a warning in this case. This ensures that the strike and oracle are always guaranteed to be in the same units.

3. Keeping Deployed Contract Addresses Consistent Across Services

The problem: After a fresh deployment, the oracle that our relayer was sending price data to was not always the same oracle that our trading contracts were querying. This meant that prices would appear uninitialized on chain, which was a subtle bug that was easy to miss.

How we fixed it: We have established a single source of truth, a deployment manifest, to serve as a reference for all contract addresses for all services. Syncing the relayer to this manifest is now a required step for all deployments.

Use of AI tools and agents

Two-mode agent (Ask / Trade): A single AI copilot supports two modes. In Ask mode, users discuss yield, covered calls, and strategy; the agent can use live asset data (yield, price, history) when a telemetry or data feed is connected. In Trade mode, the user describes a trade in natural language → the agent extracts a structured intent (writer, buyer, amount, strike, expiry) → the user confirms → the intent is submitted through the same order pipeline the frontend uses. There is no separate “AI path”; one submission flow serves both chat and UI.

Inference: The copilot uses 0G for LLM inference. In Trade mode we use prompt design and a clear intent schema so the model outputs valid, protocol-aligned intents for order submission. Model and provider are configurable; the rest of the flow is model-agnostic.

Live asset context: Before each reply in Ask or Trade mode, the copilot can pull in live yield and price data from whatever asset or telemetry source is configured, and inject a short summary into the conversation context. The agent can then reference real numbers when explaining concepts or suggesting trades—so the experience works for any underlying asset (solar, energy, or other RWA) as long as a data feed is available.

Strike at submit: When submitting a Trade intent, we do not blindly use the number from chat. We take the current asset price from the same data source that feeds the on-chain oracle and use that as the strike for the order. The on-chain option therefore matches the oracle at settlement. If no live price is available, we fall back to the user’s stated strike. This keeps settlement correct regardless of which asset or oracle is in use.

Intent flow: Intents are stored off-chain (create → confirm → submit). On confirm, the system submits the order via the same backend the UI uses; that backend holds signing keys and writes to the chain. The AI never touches private keys; it only triggers the same authenticated order path the frontend uses.

How they work together: The agent (0G-backed), live data client, and order-submission client sit in one service. Chat requests get live asset context and mode-specific prompts; in Trade mode, the model’s output is turned into an intent, then the submit path uses live price for strike and sends the order through the shared pipeline. End-to-end: natural language → structured intent → user confirmation → same on-chain path as the UI, with strike aligned to the oracle. The design is asset-agnostic: swap in a different yield or price feed and the copilot works for that asset too.