Nostra Technical Whitepaper

1.1Market Structures

Two Main Approaches

5 outcomes at 50% each:
Sum = 250%
(Converges via trading)

5 outcomes at 20% each:
Sum = 100%
(No arbitrage opportunity)

Polymarket's Hybrid Approach (NegRisk CTF)

Super Bowl (NegRisk CTF):
┌────────────┬───────┬───────┬──────────┐
│ Team       │ YES   │ NO    │ YES + NO │
├────────────┼───────┼───────┼──────────┤
│ Chiefs     │ 23¢   │ 77¢   │ 100¢ ✓   │
│ Eagles     │ 19¢   │ 81¢   │ 100¢ ✓   │
└────────────┴───────┴───────┴──────────┘

CFP (Grouped Binary):
┌────────────┬───────┬───────┬──────────┐
│ Team       │ YES   │ NO    │ YES + NO │
├────────────┼───────┼───────┼──────────┤
│ Indiana    │ 93.4¢ │ 99¢   │ 192.4¢   │
│ Ohio State │ 72¢   │ 98¢   │ 170¢     │
└────────────┴───────┴───────┴──────────┘

1.2Initial Probability Settings

The Problem with 50% Initial Probability

5 outcomes at 50% each:
Sum = 250%

Arbitrageurs:
- Buy all NO tokens
- Guaranteed profit when one outcome loses
- Creator loses to arbitrageurs

Solution: 100/n% Initial Probability

Critical Clarification: 250% Sum is NOT Arbitrage

Grouped Binary (5 outcomes × 50%):

Market 1: Team A  YES (50¢) + NO (50¢) = $1 ✓
Market 2: Team B  YES (50¢) + NO (50¢) = $1 ✓
Market 3: Team C  YES (50¢) + NO (50¢) = $1 ✓
Market 4: Team D  YES (50¢) + NO (50¢) = $1 ✓
Market 5: Team E  YES (50¢) + NO (50¢) = $1 ✓

Sum of YES = 250%... but so what?

Why no arbitrage?
• Each market is INDEPENDENT
• You CANNOT merge tokens across different markets
• Each market individually has YES + NO = $1 ✓

The 250% → 100% convergence is just PRICE DISCOVERY,
not arbitrage. Smart traders normalize it.

What IS Real Arbitrage?

Key: Arbitrage means zero risk, guaranteed profit. The 250% sum doesn't qualify.

Comparison: 5 Outcomes (True Probabilities: 60%, 15%, 10%, 10%, 5%)

The Real Problem: Stuck NO Tokens on Favorites

Conclusion: Neither Solves the Problem

True Solutions Remain:

1. CTF Multi-Outcome - No stuck inventory (can merge)
2. Market Maker - Professional takes inventory risk
3. No initial platform liquidity - Let market discover prices first
4. Accept loss as bootstrap cost - Part of business

1.3Liquidity Provision

The Bootstrap Problem

Who Provides Liquidity?

Balanced Position Strategy

For a 5-outcome market with $1000 liquidity:

Split equally: $200 per market

For each market (at 20% YES / 80% NO):
- 200 YES @ $0.20 = $40
- 200 NO @ $0.80 = $160
- Total: $200 → 200 YES + 200 NO (balanced)

If A wins:
- A: 200 YES × $1 = $200
- B: 200 NO × $1 = $200
- C: 200 NO × $1 = $200
- D: 200 NO × $1 = $200
- E: 200 NO × $1 = $200

Return: $1000 ✓ (break even when balanced)

Small Liquidity Problem

1.4Stuck Inventory Problem

The Core Issue

Initial: Market A at 20% YES / 80% NO
Creator holds: 200 YES + 200 NO

Time passes... A becomes favorite (80% YES):

Traders: "I want to BUY YES on A!"
Creator: Sells YES, happy 😊

Traders: "I don't want NO on A, A will win!"
Creator: Can't sell NO, stuck 😰

Result:
- YES: 200 → 50 (sold 150, good!)
- NO: 200 → 200 (nobody bought, stuck!)

If A wins:
- 50 YES × $1 = $50
- 200 NO × $0 = $0
Creator started with $200, ends with $50
LOSS: $150 ❌

Why Cross-Market Selling Doesn't Help

Selling NO on losing markets (B, C, D, E) does NOT compensate:

Sell 200 NO on B @ 95¢ = $190 received
But: If A wins, buyer gets 200 × $1 = $200

Creator sold $200 value for $190 = LOSS

Cross-market selling adds MORE losses, not compensation.

CTF Solves This

100 A + 100 B + 100 C + 100 D + 100 E → $100 USDC

No counterparty needed!
Always can exit via merge.
No stuck inventory problem.

Worst Case Scenario for LP

1.5Market Makers (MM)

How MMs Make Profit

MM posts orders:
BUY YES @ 49¢
SELL YES @ 51¢

When both sides fill:
- Trader A buys YES @ 51¢ → MM receives 51¢
- Trader B sells YES @ 49¢ → MM pays 49¢

MM profit: 51¢ - 49¢ = 2¢ per share
If 10,000 shares traded: Profit = $200

Taker (takes order): Pays 2% fee
Maker (provides order): Receives 0.5% rebate

MM always provides orders → earns rebate
on every trade

Price moving up?
→ Cancel BUY orders (avoid buying expensive)
→ Raise SELL prices (sell higher)

Amateur LP: Updates hourly → Gets run over
Pro MM: Updates every second → Captures spread

Correlated markets:
- "Chiefs win Super Bowl" (YES @ 25¢)
- "Mahomes wins MVP" (YES @ 30¢)

MM sells Chiefs YES, buys Mahomes YES (hedge)
Net exposure: ~zero
But: Keeps spread profit!

MM Profit Formula

MM Profit = Spread Income
          + Fee Rebates
          + Arbitrage Gains
          - Inventory Losses
          - Operating Costs

How to Attract MMs to Nostra

Key Insight: Polymarket Model

Liquidity Mirroring (Bridge Market Maker)

1.6Fee Structure

Proposed Fee Structure

The Tradeoff

Can Fees Cover Losses?

Industry Benchmarks

Fee Distribution Model

1.7AMM vs Order Book

Fundamental Difference

AMM Example: World Cup

LMSR AMM for 8 teams:

Initial pool ($5000 liquidity):
┌─────────────┬────────┬───────┬──────────────┐
│ Team        │ Tokens │ Price │ Implied Odds │
├─────────────┼────────┼───────┼──────────────┤
│ Brazil      │ 5000   │ 12.5¢ │ 12.5%        │
│ France      │ 5000   │ 12.5¢ │ 12.5%        │
│ Argentina   │ 5000   │ 12.5¢ │ 12.5%        │
│ ...         │ 5000   │ 12.5¢ │ 12.5%        │
└─────────────┴────────┴───────┴──────────────┘

Trader buys $100 Brazil:
→ Gets ~700 Brazil tokens
→ Pool Brazil: 5000 → 4300
→ Brazil price: 12.5% → 25% (automatic!)

Comparison Table

Key Insight

1.8Shared Liquidity Protocol

Nostra as a Liquidity Layer

Ecosystem Benefits

By building a shared liquidity layer, we enable:

• Any UI: Developers can build their own betting interfaces on top of Nostra without bootstrapping their own liquidity.
• Trading Bots: MMs and arbitrage bots can interact directly with the smart contracts, ensuring efficiency.
• Network Effects: Every new integration strengthens the liquidity for everyone else.

1.9Platform Economics

The Unavoidable Bootstrap Cost

Budget Example

Nostra Year 1 Plan:

Launch 50 markets
Initial liquidity: $500 per market = $25,000
Expected loss rate: 20%
Expected loss: $5,000

Think of it as:
"$5,000 marketing spend to build a prediction market"

Compare to:
- Google Ads: $10,000
- Influencer marketing: $20,000
- Traditional marketing: $50,000+

$5,000 liquidity loss = CHEAP customer acquisition

Growth Path

Polymarket's Business Model

1.10Implementation Considerations

Code Changes for 100/n% Pricing

// Prisma schema
// Price is set at market creation
model Outcome {
  currentPrice Decimal @default(0.5)
  probability  Decimal @default(50)
}

// When creating market with N outcomes
const totalOutcomes = outcomes.length;
const initialPrice = 1 / totalOutcomes;
const initialProbability = 100 / totalOutcomes;

for (const outcome of outcomes) {
  await outcomeRepository.create({
    ...outcome,
    currentPrice: initialPrice,      // 0.20 for 5 outcomes
    probability: initialProbability, // 20% for 5 outcomes
  });
}

Price Update Options

Buy A → A price up
Others unchanged
Sum drifts from 100%
Arbitrage corrects

Buy A → A price up
Others auto-decrease
Sum stays at 100%
Requires more logic

MM Bot Architecture (Optional)

// Auto-rebalancing market maker bot
const MM_CONFIG = {
  maxImbalance: 50,       // Max YES/NO difference
  spreadBps: 400,         // 4% spread
  rebalanceThreshold: 25  // Rebalance at 25 token imbalance
};

async function onTrade(market, side, amount) {
  const position = getPosition(market);
  const imbalance = Math.abs(position.yes - position.no);

  if (imbalance > MM_CONFIG.rebalanceThreshold) {
    await rebalance(market, position);
  }

  // Adjust spreads based on inventory
  await adjustSpreads(market, position);
}

async function checkToxicInventory(market) {
  const yesPrice = market.yesPrice;

  // If YES is winning big, NO is toxic
  if (yesPrice > 0.70) {
    const noTokens = getPosition(market, 'NO');
    if (noTokens > 0) {
      // Sell at ANY price before it goes to zero
      await placeSellOrder(market, 'NO', noTokens, yesPrice * 0.5);
    }
  }
}

UI Considerations

Risk Disclosure (Required)

For any LP feature (if built):

⚠️ RISK WARNING

Providing liquidity involves significant risk.

• You may lose 30-80% of deposited funds
• Fee income may NOT cover losses
• Worst case: lose almost everything

Only deposit what you can afford to lose.

1.11Decimal Precision and Dust

Understanding how fixed-point arithmetic affects token calculations in prediction markets.

The Precision Problem

// Mathematical calculation
$10 / $0.55 = 18.181818181818181818... (infinite repeating)

// With 18 decimal precision (blockchain limit)
Stored: 18.181818181818181818 (truncated)

// Multiply back to verify
18.181818181818181818 × $0.55 = $9.99999999999999999990

// The "dust"
$10.00000000000000000000
-$9.99999999999999999990
─────────────────────────
 $0.00000000000000000010  ← Lost to precision (~0.00000000000000001 cents)

Where Does The Dust Go?

In CTFExchange, the contract uses integer division which always rounds DOWN:

// CTFExchange contract - dust accumulates here
mapping(address => uint256) public balances;

Practical Impact

2.1Market Model Comparison Overview

Understanding the two primary market model architectures for prediction markets with multiple outcomes: Nostra's current Grouped Binary approach vs Polymarket's NegRisk Adapter solution.

2.2Grouped Binary Model (Nostra)

The Grouped Binary model is Nostra's current implementation. Each outcome in a multi-outcome question is treated as an independent binary market with its own YES/NO tokens.

How It Works

Key Characteristics

The Stuck Inventory Problem

2.3Liquidity Problems in Grouped Binary

Nostra's Grouped Binary model is simple, but serious liquidity issues arise in multi-outcome markets. Let's examine specific scenarios where problems occur.

📌 Scenario Setup: 2026 World Cup Winner Prediction

🔴 Problem 1: Stuck Inventory (Cannot Convert Position)

// Alice's Initial Investment
Purchased: Spain YES 1,000 tokens @ 20¢
Investment: $200
Expected Return: $1,000 if Spain wins (5x)

// One week later: Spain eliminated in group stage!
Spain YES price: 20¢ → 3¢ (85% drop)
Alice's position value: $200 → $30

Alice now thinks France will win and wants to switch her position:

// Step 1: Sell Spain YES
Sell: 1,000 tokens @ 3¢
Amount received: $30
Slippage: -10% → Actual $27

// Step 2: Buy France YES
France YES price: 25¢
Can purchase: $27 / 0.25 = 108 tokens
Slippage: +8% → Actual 100 tokens

Result: 1,000 → 100 tokens (90% loss)

// Direct Conversion via Adapter
Spain YES → France YES
Mathematical conversion (no slippage)

Value-based conversion:
$30 value → $30 value
France @ 25¢ = 120 tokens

Result: Value preserved, 20% more tokens

🔴 Problem 2: Liquidity Fragmentation

// Nostra Order Book State (Brazil YES)
Total market liquidity: $50,000 (all 5 teams)
Brazil market liquidity: $10,000 (1/5)

Order book depth:
  15¢: 5,000 shares ($750)
  16¢: 8,000 shares ($1,280)
  17¢: 10,000 shares ($1,700)
  18¢: 15,000 shares ($2,700)
  19¢: 20,000 shares ($3,800)
─────────────────────────────
  Total depth: ~$10,230

// Bob executes $10,000 market order
$750  @ 15¢ = 5,000 shares
$1,280 @ 16¢ = 8,000 shares
$1,700 @ 17¢ = 10,000 shares
$2,700 @ 18¢ = 15,000 shares
$3,570 @ 19¢ = 18,789 shares
─────────────────────────────
Total: 56,789 shares @ avg 17.6¢

Expected at 15¢: 66,667 shares
Slippage loss: ~15% (9,878 shares)

🔴 Problem 3: Price Inconsistency

Because markets are independent, the sum of all YES prices may not equal 100%:

🔴 Problem 4: LP Inventory Risk

// Charlie provides liquidity to Spain market
Provided: YES side $5,000, NO side $5,000 (total $10,000)

// Trading occurs: Users buy Spain YES heavily
Result: Charlie sells Spain YES and receives USDC
Position: Holding $8,000 Spain NO (skewed inventory)

// After Spain is eliminated
Spain NO = $1 (wins!)
Charlie profit: +$8,000

// But what if Spain had won?
Spain NO = $0 (loses)
Charlie loss: -$8,000

Problem: Cannot convert inventory to another team!
Even if Charlie wants to hedge with France NO:
1. Sell Spain NO (slippage)
2. Buy France NO (slippage)
= Double slippage makes hedging too expensive

📊 Problem Summary: Nostra vs Polymarket

2.4NegRisk Adapter (Polymarket Approach)

The key insight: Collateral is split directly into mutually exclusive YES tokens. This concentrates liquidity.

Worked Example: $10,000 Liquidity, 5 Countries

Let's see how NegRisk solves the liquidity crisis that Grouped Binary cannot handle.

5 Countries: Spain, Brazil, France, Argentina, England

Initial price: 20¢ YES / 80¢ NO each (20% probability)
Market maker: $2,000 per country → 2,000 (YES+NO) pairs each
Total liquidity: $10,000

After 5 Trades (mostly Spain YES buys)

Trade 6: Buy $100 more Spain YES...

Only 500 Spain YES left!
Price jumps: 20¢ → 30¢ → 40¢

$100 buys only 250 tokens (not 500)

1,500 Spain NO tokens sit useless 💀
Cannot move to other countries!

// Market Maker rebalances:
Collect 200 NO from each of 5 countries
= 200 complete "NO sets" (5 tokens each)
= 200 × $4 = $800 USDC

Mint 400 new Spain YES+NO pairs
→ Spain liquidity restored! ✓

Result Comparison

2.5NegRisk Architecture

Architecture Layers

Key Contracts

2.6Implementation Options

What Nostra Needs to Implement NegRisk

• 1
  WrappedCollateral.sol ERC20 wrapper around USDC for internal accounting
  Easy
• 2
  NegRiskAdapter.sol Core conversion logic: splitPosition, mergePositions, convertPosition
  Hard
• 3
  NegRiskOperator.sol Market group management, links binary markets together
  Medium
• 4
  Database: negRiskMarketId field Link markets in the same group
  Easy
• 5
  API: /api/negrisk/convert endpoint Handle conversion requests from frontend
  Medium
• 6
  Frontend: Convert Position UI Button to convert between outcomes in the same group
  Medium

Estimated Effort

3.1Oracle Strategy & Comparison

Nostra adopts a Multi-Oracle Strategy to handle various market types, ranging from crypto prices to niche local events. We benchmark against industry leaders like Opinion Labs (who use Hybrid AI + Optimistic Oracles) and Polymarket (UMA).

Comparative Analysis: Three Oracle Tiers

Adoption Roadmap: Step-by-Step Evolution

3.2Optimistic Oracle (UMA) Integration

For markets where verifiable on-chain data or APIs are unavailable (e.g., "Will this YouTuber reach 1M subscribers?" or highly subjective "Opinion" markets), we utilize UMA's Optimistic Oracle. This allows humans to resolve markets with crypto-economic guarantees.

The "Optimistic" Mechanism

Resolution Call Flow

Hybrid Implementation: Opinion AI + UMA

To scale resolution for unstructured markets, we employ a Hybrid AI approach similar to Opinion Labs. This combines the speed of AI with the security of the Optimistic Oracle.

3.3OptimisticOracleV3 Specification

The OptimisticOracleV3 is the core contract governing assertion lifecycles. It utilizes an escalation game where truth is assumed unless disputed.

Key Functions

// Core OOv3 Interface
interface IOptimisticOracleV3 {
    /**
     * @notice Asserts a truth about a world state.
     * @param claim Encoded data or string representing the statement (e.g. "BTC > 50k at block 100").
     * @param asserter Address that receives the bond back if correct.
     * @param callbackRecipient Address to notify when settled.
     * @return assertionId Unique ID for this assertion.
     */
    function assertTruthWithDefaults(
        bytes calldata claim,
        address asserter
    ) external returns (bytes32 assertionId);

    /**
     * @notice Settles the assertion. Can only be called after liveness period.
     * @return bool True if the assertion was resolved as TRUTHFUL.
     */
    function settleAndGetAssertionResult(bytes32 assertionId) external returns (bool);

    /**
     * @notice View function to check status.
     */
    function getAssertionResult(bytes32 assertionId) external view returns (bool);
}

Integration Logic in Nostra

• Assertion: We call assertTruthWithDefaults. This pulls the Minimum Bond (usually WETH or USDC) from the asserter.
• Liveness Period: Defaults to 7200 seconds (2 hours). During this window, any bot can call `disputeAssertion`.
• Settlement: Once the window closes without dispute, we call settleAndGetAssertionResult. If it returns true, Nostra pays out the winners.

Dispute Flow

• Monitoring: Watchdog bots verify assertions against real-world data.
• Challenge: If a discrepancy is found, the bot calls disputeAssertion. This moves the adjudication to UMA's Data Verification Mechanism (DVM).
• DVM Voting: UMA token holders vote on the specific truth.
• Reward: If the dispute was valid, the challenger receives the Asserter's bond as a bounty.

3.4Getting Started with Chainlink

Before integrating Chainlink oracles into Nostra, there are essential preparation steps to ensure smooth operation and cost management.

Step 1: Acquire LINK Tokens

Step 2: Set Up Subscription (for Chainlink Functions)

Step 3: Deploy Consumer Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import {FunctionsClient} from "@chainlink/contracts/src/v0.8/functions/v1_0_0/FunctionsClient.sol";
import {FunctionsRequest} from "@chainlink/contracts/src/v0.8/functions/v1_0_0/libraries/FunctionsRequest.sol";

contract NostraMarketResolver is FunctionsClient {
    using FunctionsRequest for FunctionsRequest.Request;

    // Subscription ID from Chainlink Functions UI
    uint64 private subscriptionId;

    // Gas limit for callback
    uint32 private constant GAS_LIMIT = 300000;

    // DON ID for the network (e.g., "fun-polygon-mainnet-1")
    bytes32 private donId;

    constructor(
        address router,
        uint64 _subscriptionId,
        bytes32 _donId
    ) FunctionsClient(router) {
        subscriptionId = _subscriptionId;
        donId = _donId;
    }

    // Request market resolution
    function requestResolution(
        bytes32 marketId,
        string calldata source,
        string[] calldata args
    ) external returns (bytes32 requestId) {
        FunctionsRequest.Request memory req;
        req.initializeRequestForInlineJavaScript(source);

        if (args.length > 0) {
            req.setArgs(args);
        }

        requestId = _sendRequest(
            req.encodeCBOR(),
            subscriptionId,
            GAS_LIMIT,
            donId
        );
    }
}

Step 4: Estimate and Budget LINK Costs

Step 5: Security Best Practices

3.5Chainlink Products Overview

Detailed Product Summaries

// Simple usage - read price directly
(, int256 price, , , ) = priceFeed.latestRoundData();
bool yesWins = price > threshold;

// Automation-compatible contract
function checkUpkeep(bytes calldata) external view returns (bool upkeepNeeded, bytes memory) {
    upkeepNeeded = block.timestamp >= market.deadline && !market.resolved;
}
function performUpkeep(bytes calldata) external { resolveMarket(); }

// Request random number
uint256 requestId = COORDINATOR.requestRandomWords(keyHash, subId, confirmations, gasLimit, numWords);

// Callback with verified random
function fulfillRandomWords(uint256, uint256[] memory randomWords) internal override {
    winner = participants[randomWords[0] % participants.length];
}

When to Use Each Product

3.5Resolution Architecture

Current vs Proposed Flow

3.6Smart Contract Integration

Functions Client Example (Request)

// FunctionsClient.sol (Inherited by our market contract)
import { FunctionsClient } from "@chainlink/.../FunctionsClient.sol";
import { FunctionsRequest } from "@chainlink/.../FunctionsRequest.sol";

contract NostraMarket is FunctionsClient {
    using FunctionsRequest for FunctionsRequest.Request;

    address router = 0x...; // Chainlink Router (Oracle Contract)
    bytes32 donId = 0x...;  // DON ID
    uint64 subscriptionId = 1234; // My Subscription ID

    // This function calls the Chainlink Router contract
    function resolveMarket() external {
        
        // 1. Create Request (Include JS Logic)
        FunctionsRequest.Request memory req;
        req.initializeRequestForInlineJavaScript("const apiResponse = await Functions.makeHttpRequest(...)");

        // 2. Send to Chainlink Router (Step 1 in Diagram)
        bytes32 requestId = _sendRequest(
            req.encodeCBOR(),
            subscriptionId,
            gasLimit,
            donId
        );
        
        // 3. Store ID for verification
        pendingRequests[requestId] = true;
    }
}
            

Price Feed Resolver Example

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract PriceFeedResolver {
    AggregatorV3Interface internal priceFeed;
    IConditionalTokens public ctf;

    struct PriceMarket {
        bytes32 questionId;
        uint256 threshold;      // Price threshold in 8 decimals
        bool resolveAbove;      // true = YES wins if price > threshold
        uint256 deadline;
        bool resolved;
    }

    mapping(bytes32 => PriceMarket) public markets;

    function resolveMarket(bytes32 questionId) external {
        PriceMarket storage market = markets[questionId];
        require(!market.resolved, "Already resolved");
        require(block.timestamp >= market.deadline, "Too early");

        // Get latest price from Chainlink
        (, int256 price, , , ) = priceFeed.latestRoundData();

        // Determine winner
        bool yesWins = market.resolveAbove
            ? price > int256(market.threshold)
            : price < int256(market.threshold);

        // Report payouts to CTF
        uint256[] memory payouts = new uint256[](2);
        payouts[0] = yesWins ? 1 : 0;  // YES outcome
        payouts[1] = yesWins ? 0 : 1;  // NO outcome

        ctf.reportPayouts(questionId, payouts);
        market.resolved = true;
    }
}
            

Chainlink Functions Example (JavaScript)

// This code runs in Chainlink Functions DON
const apiEndpoint = args[0];  // e.g., "https://api.sportsdata.io/..."
const jsonPath = args[1];     // e.g., "Games[0].Winner"

const response = await Functions.makeHttpRequest({
  url: apiEndpoint,
  headers: { "Ocp-Apim-Subscription-Key": secrets.apiKey }
});

if (response.error) {
  throw Error("API request failed");
}

// Navigate JSON path and return result
const homeTeamWins = result === "HomeTeam" ? 1 : 0;
return Functions.encodeUint256(homeTeamWins);
            

Network Addresses

LINK: 0x84b9B910527Ad5C03A9Ca831909E21e236EA7b06
BTC/USD: 0x5741306c21795FdCBb9b265Ea0255F499DFe515C
ETH/USD: 0x143db3CEEfbdfe5631aDD3E50f7614B6ba708BA7
BNB/USD: 0x2514895c72f50D8bd4B4F9b1110F0D6bD2c97526

Functions Router: 0xC22a79eBA640940ABB6dF0f7982cc119578E11De
BTC/USD: 0xe7656e23fE8077D438aEfbec2fAbDf2D8e070C4f
ETH/USD: 0xF0d50568e3A7e8259E16663972b11910F89BD8e7

3.7Cost & Security Considerations

Monthly Cost Estimation (100 markets)

Security Considerations

4.1Deployment Networks

Strategic Priorities

The Criticality of Gas Fees in Batch Processing

For optimal UX, our server will likely batch process user actions (e.g., matching 50 orders in one transaction) to provide instant confirmation and gasless experience for users. This makes gas fees a direct operating cost for the platform.

Conclusion: If we subsidize gas or run batch processors, L2s like Arbitrum are currently too expensive at scale. Polygon or BSC is mandatory for economic viability.

Comparative Analysis: L1 vs L2

Primary Recommendation: BNB Smart Chain (BSC)

While Polygon remains a viable backup due to its low fees, BSC's combination of raw performance and strategic ecosystem alignment makes it the optimal launchpad for Nostra.

4.2Bridging Strategy (CCIP)

Why Bridge?

Solution: Chainlink CCIP (Cross-Chain Interoperability Protocol)

CCIP allows us to accept deposits from any supported chain and route them to our specific market implementation.

Integration Architecture

Benefits of CCIP

• Unified Liquidity: Treat users from all chains as if they are on one.
• Simplified UX: "Deposit & Bet" in one transaction (abstracting the bridge).
• Security: Risk Management Network (secondary validation) prevents hacks common in standard bridges.

5.1Market Creation Process (Under the Hood)

The "Gasless" Creator Experience

Nostra abstracts the complexity of blockchain interaction from market creators. When a user clicks "Start Batch Creation", the server handles all on-chain operations asynchronously.

Step-by-Step Execution

Detailed Token Flow: Liquidity & Seeding

To ensure markets are tradable immediately, the Server Wallet acts as the initial liquidity provider. This involves a specific sequence of token transfers:

5.2Claiming Process (Double Confirmation)

Why two transactions?

Users often ask why claiming winnings requires two wallet confirmations. This is due to the architectural separation between the Conditional Tokens Framework (CTF) and the Nostra Exchange Contract.

contract.redeemPositions(...)

exchange.deposit(...)

Why not automatic deposit?

A common question is: "Why can't the Redemption step automatically send funds to the Exchange?"

• Protocol Separation: The `redeemPositions` function belongs to the standard Gnosis CTF Core contract. This is a neutral, immutable primitive that knows nothing about our specific Exchange contract.
• Security & Control: The CTF contract is designed to return collateral only to the token holder. It cannot be forced to trigger a subsequent deposit into another contract arbitrarily.
• Manual Step Required: Therefore, the user must first receive the funds (Step 1) and then explicitly approve/deposit them into the Exchange (Step 2).