# Technical Documentation

## CRYPTO CAST PROTOCOL <a href="#cryptocastprotocol" id="cryptocastprotocol"></a>

### Decentralized Prediction Market with Tokenized Intelligence <a href="#decentralizedpredictionmarketwithtokenizedintelligence" id="decentralizedpredictionmarketwithtokenizedintelligence"></a>

**Version:** 1.0\
**Network:** Binance Smart Chain (BSC)\
**Last Updated:** March 2026

***

### EXECUTIVE SUMMARY <a href="#executivesummary" id="executivesummary"></a>

Crypto Cast is a decentralized prediction market protocol that enables users to trade tokenized prediction assets without intermediaries. Unlike traditional betting houses, each position is a real token (ERC-1155) on the blockchain, verifiable on-chain and resolved by decentralized oracles.

The protocol uses Conditional Tokens (CT) to represent positions in binary event outcomes (YES/NO), ensuring complete transparency, cryptographic security, and elimination of centralized manipulation risk.

**Key Features:**

* Tokenized prediction assets (ERC-1155)
* Oracle-verified resolution via UMA Optimistic Oracle V3
* Decentralized liquidity via Pancake Swap
* Transparent fee structure (30% of winning pool)
* 100% on-chain operation on BSC

***

### 1. TECHNICAL OVERVIEW <a href="#id-1technicaloverview" id="id-1technicaloverview"></a>

#### 1.1 Conditional Tokens (CT) Definition <a href="#id-11conditionaltokensctdefinition" id="id-11conditionaltokensctdefinition"></a>

Conditional Tokens are ERC-1155 tokens that represent positions in binary event outcomes. Each event generates a unique pair of tokens:

**YES Token:** Represents the prediction of a positive outcome. Worth $1.00 USDT if the event resolves YES, $0.00 if it resolves NO.

**NO Token:** Represents the prediction of a negative outcome. Worth $1.00 USDT if the event resolves NO, $0.00 if it resolves YES.

**Fundamental Invariant:** YES Token + NO Token = $1.00 USDT always, regardless of market state.

#### 1.2 Basic User Flow <a href="#id-12basicuserflow" id="id-12basicuserflow"></a>

1. **Deposit:** User deposits USDT into the Prediction Position Manager contract
2. **Minting:** The protocol automatically mints 1 CT YES + 1 CT NO for each USDT deposited
3. **Trading:** User buys/sells these tokens on the decentralized orderbook (Prediction Exchange)
4. **Resolution:** After the event, oracles resolve the outcome (YES or NO)
5. **Redemption:** Winning tokens are redeemed for $1.00 USDT each; losing tokens are worth $0.00
6. **Withdrawal:** User withdraws USDT to their wallet

#### 1.3 Unique Market Identification <a href="#id-13uniquemarketidentification" id="id-13uniquemarketidentification"></a>

Each market/event generates a unique tokenId (256-bit number) that identifies the specific YES/NO pair for that event. This tokenId is deterministic and based on event parameters (description, resolution date, oracle, etc).

Example tokenId: `115792089237316195423570985008687907853269984665640564039457584007913129639935`

***

### 2. TECHNICAL ARCHITECTURE <a href="#id-2technicalarchitecture" id="id-2technicalarchitecture"></a>

#### 2.1 Core Components <a href="#id-21corecomponents" id="id-21corecomponents"></a>

**2.1.1 Crypto Cast Conditional Token Contract**

**Address:** `0x364d05055614B506e2b9A287E4ac34167204cA83`\
**Standard:** ERC-1155\
**Function:** Centralized vault storing all Conditional Tokens (YES/NO) from all events.

**Responsibilities:**

* Minting YES/NO pairs when USDT is deposited
* Burning tokens when redeemed for USDT
* Balance tracking by user and tokenId
* Support for transfers and approvals (ERC-1155 standard)

**Critical Functions:**

* `mint(address to, uint256 id, uint256 amount, bytes data)` — Mints conditional tokens
* `burn(address from, uint256 id, uint256 amount)` — Burns tokens on resolution
* `balanceOf(address account, uint256 id)` — Returns balance of specific token
* `safeTransferFrom(...)` — Safe transfer between users

**2.1.2 Prediction Position Manager**

**Address:** `0x0F963049F7dbd1e4899A361DeB42e9aB3A6e5129`\
**Function:** Manages investor positions. Entry point for deposits and withdrawals.

**Responsibilities:**

* Receive USDT deposits
* Authorize Conditional Token minting
* Track user positions (USDT equivalent balance)
* Process withdrawals (token burning + USDT transfer)
* Maintain transaction history

**Deposit Flow:**

1. User approves USDT transfer to this contract
2. User calls `deposit(uint256 amount)`
3. Contract transfers USDT from user
4. Contract authorizes CryptoCast CT to mint tokens
5. Crypto Cast CT mints 1 YES + 1 NO per USDT
6. Tokens are credited to user
7. `Deposited(user, amount)` event is emitted

**Withdrawal Flow:**

1. User calls `withdraw(uint256 amount)`
2. Contract validates sufficient user balance
3. Contract burns equivalent YES and NO tokens
4. Contract transfers USDT back to user
5. `Withdrawn(user, amount)` event is emitted

**2.1.3 Prediction Exchange (Settlement Contract)**

**Address:** `0xF99F5367ce708c66F0860B77B4331301A5597c86`\
**Function:** Decentralized orderbook and event resolution contract.

**Responsibilities:**

* Maintain orderbook for CT buy/sell
* Execute trades between users
* Propose event results via UMA Optimistic Oracle V3
* Manage dispute window (\~2 hours)
* Liquidate positions after resolution
* Distribute USDT to winners

**Trading Flow:**

1. User A creates order: "Selling 100 YES @ $0.65"
2. User B creates order: "Buying 100 YES @ $0.65"
3. Orders are matched automatically
4. Tokens are transferred (A receives 100 NO, B receives 100 YES)
5. USDT is settled (B pays 65 USDT, A receives 65 USDT)
6. `TradeExecuted(...)` event is emitted

**Resolution Flow:**

1. After event closing date, anyone can propose result via UMA
2. Proposal is recorded on-chain with timestamp
3. Dispute window opens for \~2 hours
4. Anyone can contest the proposal (requires stake)
5. If no contest, result is finalized
6. If contested, UMA arbitrates (outside this contract scope)
7. After finalization, users can redeem winning tokens

**Redemption Flow:**

1. User calls `redeemWinningTokens(uint256 eventId)`
2. Contract verifies event has been resolved
3. Contract burns user's YES/NO tokens
4. Contract transfers equivalent USDT ($1.00 per winning token)
5. `TokensRedeemed(user, amount)` event is emitted

**2.1.4 Liquidity Pool (Pancake Swap)**

**Address:** `0x46Cf1cF8c69595804ba91dFdd8d6b960c9B0a7C4`\
**Function:** Decentralized liquidity pool for CT trading against USDT.

**Responsibilities:**

* Provide liquidity for YES/USDT and NO/USDT pairs
* Execute swaps with AMM-based slippage (Automated Market Maker)
* Charge LP fee (0.25% standard Pancake)

**Note:** This is a standard Pancake Swap pool. Users can deposit liquidity and earn trading commissions.

#### 2.2 Data Flow Between Contracts <a href="#id-22dataflowbetweencontracts" id="id-22dataflowbetweencontracts"></a>

```
User
  ↓
[Prediction Position Manager] ← USDT Deposits/Withdrawals
  ↓
[CryptoCast Conditional Token] ← CT Minting/Burning
  ↓
[Prediction Exchange] ← CT Trading
  ↓
[Pancake Swap LP] ← Decentralized Liquidity
  ↓
[UMA Optimistic Oracle V3] ← Event Resolution
```

#### 2.3 UMA Optimistic Oracle V3 Integration <a href="#id-23umaoptimisticoraclev3integration" id="id-23umaoptimisticoraclev3integration"></a>

**Oracle Used:** UMA Optimistic Oracle V3\
**Function:** Resolve binary events in a decentralized, censorship-resistant manner.

**Resolution Flow:**

1. **Proposition (On-Chain):** Anyone proposes result (YES or NO) for specific event, including:
   * Event ID
   * Proposed result (YES/NO)
   * Proposition timestamp
   * Security stake (in UMA tokens)
2. **Dispute Window (\~2 hours):** During this period:
   * Anyone can contest the proposal
   * Contestor must stake equivalent amount
   * If no contest, result is accepted
3. **Arbitration (if contested):** UMA resolves dispute through:
   * Decentralized voting by token holders
   * Deterministic resolution based on verifiable data
   * Penalization of dishonest proposers/contestors
4. **Finalization:** Result is recorded on-chain and immutable

**Advantages:**

* No centralized intermediaries
* Censorship-resistant
* Economically incentivized (stake mechanism)
* Verifiable on-chain

***

### 3. TOKENOMICS <a href="#id-3tokenomics" id="id-3tokenomics"></a>

#### 3.1 Tokens Used <a href="#id-31tokensused" id="id-31tokensused"></a>

**3.1.1 USDT (ERC-20)**

**Function:** Protocol collateral and settlement currency.

**Flows:**

* Deposits: User → Prediction Position Manager
* Withdrawals: Prediction Position Manager → User
* Trade settlement: Buyer → Seller (via Prediction Exchange)
* Winning token redemption: Prediction Exchange → User

**Supply:** Not controlled by protocol (external token)

**3.1.2 Conditional Tokens (ERC-1155)**

**Function:** Represent positions in binary events.

**Characteristics:**

* Not directly transferable between users (only via Prediction Exchange)
* Always in pairs (YES + NO)
* Aggregate value always = $1.00 USDT
* Burned on event resolution

**Supply:** Dynamic, based on deposits (1 YES + 1 NO per USDT deposited)

#### 3.2 Fee Economics <a href="#id-32feeeconomics" id="id-32feeeconomics"></a>

**3.2.1 Protocol Fee (30% of Winning Pool)**

The primary protocol revenue source is a 30% fee charged on the winning pool of each event.

**Example:**

* Event: "Bitcoin will pass $100k by 12/31/2026?"
* Total staked: $10,000 USDT
* Result: YES wins
* Winning pool: $10,000 USDT
* Protocol fee: 30% × $10,000 = $3,000 USDT
* Distributed to winners: 70% × $10,000 = $7,000 USDT

**Fee Allocation:**

* Protocol development and operation
* Liquidity incentives
* Security reserves
* Future expansions

**3.2.2 Network Fee (BSC)**

All on-chain transactions incur BSC network gas fees:

* Deposit: \~$0.10 - $0.50 USD
* Withdrawal: \~$0.10 - $0.50 USD
* Trade: \~$0.20 - $1.00 USD
* Redemption: \~$0.10 - $0.50 USD

These fees go to BSC validators, not the protocol.

**3.2.3 Trading Fee (1.7% - 1.8%)**

Charged on each orderbook trade execution:

* Applied to transaction notional value
* Example: Buy 100 YES @ $0.65 = $65 USDT
* Fee: 1.75% × $65 = $1.1375 USDT
* Net amount seller receives: $63.8625 USDT

**Distribution:**

* Protocol: Percentage for operation
* Liquidity: Incentives for liquidity providers

**3.2.4 Pancake Swap Fee**

Liquidity pool charges 0.25% on each swap (standard Pancake):

* Example: Swap 100 YES for USDT
* Fee: 0.25% of volume
* Distributed to LPs (liquidity providers)

#### 3.3 Revenue Flow <a href="#id-33revenueflow" id="id-33revenueflow"></a>

```
User A deposits $1,000 USDT
  ↓
User A receives 1,000 YES + 1,000 NO
  ↓
User A sells 500 YES @ $0.70 to User B
  ├─ Trading fee: 1.75% × $350 = $6.125 USDT
  ├─ User B pays: $350 + $6.125 = $356.125 USDT
  └─ User A receives: $350 - $6.125 = $343.875 USDT
  ↓
Event resolves YES
  ├─ User A has: 500 YES + 1,000 NO
  ├─ User B has: 500 YES
  ↓
Winning tokens redeemed
  ├─ User A redeems 500 YES = $500 USDT
  ├─ User B redeems 500 YES = $500 USDT
  ├─ Total winning pool: $1,000 USDT
  ├─ Protocol fee: 30% × $1,000 = $300 USDT
  └─ Distributed to winners: 70% × $1,000 = $700 USDT
```

***

### 4. USER FLOWS <a href="#id-4userflows" id="id-4userflows"></a>

#### 4.1 Complete Flow: Deposit to Withdrawal <a href="#id-41completeflowdeposittowithdrawal" id="id-41completeflowdeposittowithdrawal"></a>

**Step 1: USDT Approval**

```
User → USDT Contract: approve(Prediction Position Manager, amount)
```

User authorizes contract to transfer USDT on their behalf.

**Step 2: Deposit**

```
User → Prediction Position Manager: deposit(1000e6)
```

* Prediction Position Manager transfers 1,000 USDT from user
* Authorizes CryptoCast CT to mint
* Crypto Cast CT mints 1,000 YES + 1,000 NO
* Tokens are credited to user
* User balance: 1,000 YES + 1,000 NO

**Step 3: Trading Approval**

```
User → Crypto Cast CT: setApprovalForAll(Prediction Exchange, true)
```

User authorizes Prediction Exchange to transfer their Conditional Tokens.

**Step 4: Create Sell Order**

```
User → Prediction Exchange: createSellOrder(
  eventId: 12345,
  tokenType: YES,
  amount: 500,
  price: 0.70e6
)
```

User places order to sell 500 YES @ $0.70 each.

**Step 5: Trade Execution**

```
Buyer → Prediction Exchange: fillOrder(orderId)
```

* Buyer pays: 500 × $0.70 = $350 USDT
* Trading fee: 1.75% × $350 = $6.125 USDT
* Seller receives: $350 - $6.125 = $343.875 USDT
* Buyer receives: 500 YES
* Seller loses: 500 YES

**Step 6: Wait for Resolution**

User waits until event closing date.

**Step 7: Result Proposition (by anyone)**

```
Proposer → UMA Oracle: proposeResult(
  eventId: 12345,
  result: YES,
  stake: 100e18
)
```

Result is proposed on-chain. Dispute window opens for 2 hours.

**Step 8: Final Resolution**

After dispute window with no contest, result is finalized on-chain.

**Step 9: Redeem Winning Tokens**

```
User → Prediction Exchange: redeemWinningTokens(eventId)
```

* User has: 500 YES + 1,000 NO
* Event resolved YES
* User redeems 500 YES = $500 USDT
* NO tokens worth $0 (lost)
* User balance: $500 USDT + 1,000 NO (worthless)

**Step 10: Withdrawal**

```
User → Prediction Position Manager: withdraw(500e6)
```

* User withdraws $500 USDT to wallet
* Final balance: $500 USDT in user's wallet

#### 4.2 Liquidity Provider Flow (Pancake Swap) <a href="#id-42liquidityproviderflowpancakeswap" id="id-42liquidityproviderflowpancakeswap"></a>

**Step 1: Token Approvals**

```
LP → Crypto Cast CT: setApprovalForAll(Pancake Router, true)
LP → USDT: approve(Pancake Router, amount)
```

**Step 2: Liquidity Deposit**

```
LP → Pancake Router: addLiquidity(
  YES_token: 500e18,
  USDT: 350e6,
  minYES: 490e18,
  minUSDT: 340e6
)
```

LP deposits 500 YES + 350 USDT (ratio \~1.43:1, reflecting $0.70 price).

**Step 3: Receive LP Tokens**

```
Pancake → LP: transfer(LP_tokens)
```

LP receives tokens representing their pool share.

**Step 4: Earn Commissions**

Every trade in the pool generates 0.25% distributed to LPs proportionally.

**Step 5: Withdraw Liquidity**

```
LP → Pancake Router: removeLiquidity(
  LP_tokens: amount,
  minYES: ...,
  minUSDT: ...
)
```

LP withdraws their share + earned commissions.

***

### 5. SECURITY & AUDIT <a href="#id-5securityaudit" id="id-5securityaudit"></a>

#### 5.1 Security Mechanisms <a href="#id-51securitymechanisms" id="id-51securitymechanisms"></a>

**5.1.1 Collateral Invariant**

The protocol guarantees:

* For each YES token in circulation, 1 USDT in collateral exists
* For each NO token in circulation, 1 USDT in collateral exists
* Total collateral ≥ Total YES tokens + Total NO tokens

Violation of this invariant is impossible due to ERC-1155 architecture.

**5.1.2 Decentralized Oracle Resolution**

* UMA Optimistic Oracle V3 is censorship-resistant
* Requires economic stake for proposition and contest
* Decentralized voting on disputes
* Immutable history on blockchain

**5.1.3 Exposure Limits**

Each event may have maximum USDT collateral limit to mitigate systemic risk.

**5.1.4 Emergency Pauses**

Contracts include pause functions (multisig) for:

* Stopping minting on exploit
* Stopping trading on oracle failure
* Stopping withdrawals on insolvency

#### 5.2 Known Risks <a href="#id-52knownrisks" id="id-52knownrisks"></a>

**5.2.1 Oracle Risk**

* If UMA is compromised, results could be incorrect
* Mitigation: UMA is established protocol with proven security

**5.2.2 Smart Contract Risk**

* Bugs in contracts could lead to fund loss
* Mitigation: Security audit recommended

**5.2.3 Liquidity Risk**

* If Pancake pool becomes illiquid, users may not exit
* Mitigation: Incentives for liquidity providers

**5.2.4 Counterparty Risk**

* Users depend on Prediction Exchange being online
* Mitigation: Contracts are decentralized, no central server

***

### 6. USE CASES <a href="#id-6usecases" id="id-6usecases"></a>

#### 6.1 Prediction Trader <a href="#id-61predictiontrader" id="id-61predictiontrader"></a>

Alice believes Ethereum will pass $5,000 by 06/30/2026.

1. Deposits $1,000 USDT
2. Receives 1,000 YES + 1,000 NO
3. Sells 500 NO @ $0.30 (market price)
4. Receives $150 USDT
5. Now has: 1,000 YES + 500 NO + $150 USDT cash
6. If Ethereum passes $5,000: 1,000 YES = $1,000 USDT
7. Profit: $1,000 - $1,000 (initial) + $150 (NO sale) = $150 USDT

#### 6.2 Liquidity Provider <a href="#id-62liquidityprovider" id="id-62liquidityprovider"></a>

Bob wants to earn commissions providing liquidity.

1. Deposits 1,000 YES + 700 USDT into Pancake pool
2. Receives LP tokens
3. Each pool trade generates 0.25% commission
4. After 1 month, pool generated $500 volume
5. Bob earned: 0.25% × $500 = $1.25 USDT in commissions
6. Withdraws liquidity: 1,000 YES + 700 USDT + $1.25 USDT

#### 6.3 Arbitrageur <a href="#id-63arbitrageur" id="id-63arbitrageur"></a>

Charlie detects price discrepancy between CryptoCast and another market.

1. In Crypto  Cast, YES trades @ $0.60
2. In another market, YES trades @ $0.65
3. Charlie buys 1,000 YES in CryptoCast @ $0.60 = $600 USDT
4. Charlie sells 1,000 YES in other market @ $0.65 = $650 USDT
5. Profit (minus fees): \~$50 USDT

***

### 7. ROADMAP <a href="#id-7roadmap" id="id-7roadmap"></a>

#### Phase 1: Market Expansion (Q2 2026) <a href="#phase1marketexpansionq22026" id="phase1marketexpansionq22026"></a>

* Add 50+ new prediction events
* Coverage: Cryptocurrencies, Elections, Sports, Climate
* Integration with additional data sources

#### Phase 2: UX Optimization (Q3 2026) <a href="#phase2uxoptimizationq32026" id="phase2uxoptimizationq32026"></a>

* Simplified interface for beginners
* Mobile app (iOS/Android)
* Real-time notifications

#### Phase 3: Multichain Expansion (Q4 2026) <a href="#phase3multichainexpansionq42026" id="phase3multichainexpansionq42026"></a>

* Support for Ethereum, Polygon, Arbitrum
* Conditional Token bridge between chains
* Cross-chain liquidity aggregation

#### Phase 4: Decentralized Governance (2027) <a href="#phase4decentralizedgovernance2027" id="phase4decentralizedgovernance2027"></a>

* DAO for protocol decisions
* Community voting on parameters
* Revenue distribution to stakeholders

***

### 8. MARKETING POSITIONING <a href="#id-8marketingpositioning" id="id-8marketingpositioning"></a>

#### 8.1 Differentiators vs. Traditional Betting Houses <a href="#id-81differentiatorsvstraditionalbettinghouses" id="id-81differentiatorsvstraditionalbettinghouses"></a>

| Aspect            | Betting House            | CryptoCast                |
| ----------------- | ------------------------ | ------------------------- |
| Transparency      | Opaque, controlled       | 100% on-chain, verifiable |
| Manipulation Risk | High (house always wins) | None (decentralized)      |
| Resolution        | Centralized              | Decentralized oracle      |
| Assets            | Database numbers         | Real tokens on blockchain |
| Liquidity         | House-provided           | User-provided             |
| Censorship        | Possible                 | Impossible                |

#### 8.2 Key Messages <a href="#id-82keymessages" id="id-82keymessages"></a>

**"Prediction Assets"** — Users don't bet; they acquire tokenized prediction assets on the blockchain, verifiable on-chain.

**"Tokenized Intelligence"** — Each position is a real token (ERC-1155) on BSC, not a database number in a company's system.

**"Trade Your Conviction"** — Unlike traditional betting, users own digital assets that appreciate or depreciate in real-time as markets move.

**"Decentralized & Transparent"** — All positions recorded on blockchain, no manipulation, no "house always wins".

**"Oracle-Verified Outcomes"** — Results resolved by decentralized oracles (UMA), not by a company.

#### 8.3 Target Audience <a href="#id-83targetaudience" id="id-83targetaudience"></a>

* **Crypto Traders:** Already familiar with blockchain, seeking new markets
* **Institutional Investors:** Seeking transparency and decentralization
* **DeFi Community:** Users of Uniswap, Aave, Curve protocols
* **Traditional Bettors:** Seeking decentralized alternative

***

### 9. CONCLUSION <a href="#id-9conclusion" id="id-9conclusion"></a>

Crypto Cast is a decentralized prediction market protocol combining the sophistication of traditional financial markets with blockchain transparency and security.

Through Conditional Tokens (ERC-1155), UMA Optimistic Oracle V3, and fully on-chain architecture, Crypto Cast offers users a secure, verifiable, and censorship-resistant way to trade predictions on real-world events.

With clear fee structure (30% of winning pool), Pancake Swap liquidity integration, and ambitious expansion roadmap, CryptoCast is positioned to become the leading decentralized prediction market on BSC.

***

### 10. USEFUL LINKS <a href="#id-10usefullinks" id="id-10usefullinks"></a>

**Platform:** <https://cryptocast.markets>

**BNB Smart Chain Explorer:** <https://bscscan.com>

**Telegram (Official Channel):** <https://t.me/CryptoCastmarkets>

&#x20;**X (Official Profile):** <https://x.com/cryptocastdefi\\>
\
**YouTube (Official Channel):** <https://www.youtube.com/@CRYPTOCASTDEFI><br>

***

### TECHNICAL REFERENCES <a href="#technicalreferences" id="technicalreferences"></a>

**Contract Addresses (BSC):**

* Crypto Cast Conditional Token: `0x364d05055614B506e2b9A287E4ac34167204cA83`
* Prediction Position Manager: `0x0F963049F7dbd1e4899A361DeB42e9aB3A6e5129`
* Prediction Exchange: `0xF99F5367ce708c66F0860B77B4331301A5597c86`
* Liquidity Pool (Pancake): `0x46Cf1cF8c69595804ba91dFdd8d6b960c9B0a7C4`

**Standards Used:**

* ERC-20: Standard token (USDT)
* ERC-1155: Conditional Tokens
* UMA Optimistic Oracle V3: Event resolution

***

**© 2026 Crypto Cast. All rights reserved.**

*This document is provided for informational purposes only and does not constitute investment advice, legal advice, or an offer to sell or solicitation to buy any securities or tokens.*


---

# Agent Instructions: 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:

```
GET https://cryptocast.gitbook.io/cryptocast-docs/technical-documentation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.