Nostra 기술 백서

1.1시장 구조

두 가지 주요 접근 방식

5개 결과가 각각 50%일 때:
합계 = 250%
(거래를 통해 수렴)

5개 결과가 각각 20%일 때:
합계 = 100%
(차익거래 기회 없음)

Polymarket의 하이브리드 접근 방식 (NegRisk CTF)

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

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

1.2초기 확률 설정

50% 초기 확률의 문제점

5개 결과가 각각 50%일 때:
합계 = 250%

차익거래자:
- 모든 NO 토큰 매수
- 한 결과가 패배할 때 보장된 수익
- 제작자는 차익거래자에게 손실

해결책: 100/n% 초기 확률

중요한 설명: 250% 합계는 차익거래가 아닙니다

Grouped Binary (5개 결과 × 50%):

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

YES의 합 = 250%... 하지만 그래서요?

왜 차익거래가 아닌가?
• 각 시장은 독립적입니다
• 다른 시장 간에 토큰을 병합할 수 없습니다
• 각 시장은 개별적으로 YES + NO = $1 ✓

250% → 100% 수렴은 단지 가격 발견(Price Discovery)일 뿐,
차익거래가 아닙니다. 스마트 트레이더들이 이를 정상화합니다.

진짜 차익거래란 무엇인가?

핵심: 차익거래는 무위험, 보장된 수익을 의미합니다. 250% 합계는 이에 해당하지 않습니다.

비교: 5개 결과 (실제 확률: 60%, 15%, 10%, 10%, 5%)

진짜 문제: 우승후보에 대한 고립된 NO 토큰

결론: 둘 다 문제를 해결하지 못함

진정한 해결책:

1. CTF 다중 결과 - 재고 고립 없음 (병합 가능)
2. 마켓 메이커 - 전문가가 재고 위험 감수
3. 초기 플랫폼 유동성 없음 - 시장이 먼저 가격을 발견하게 함
4. 손실을 부트스트랩 비용으로 감수 - 비즈니스의 일부

1.3유동성 공급

부트스트랩 문제

누가 유동성을 공급하는가?

균형 포지션 전략

$1000 유동성으로 5개 결과 시장의 경우:

균등 분할: 시장당 $200

각 시장에 대해 (20% YES / 80% NO):
- 200 YES @ $0.20 = $40
- 200 NO @ $0.80 = $160
- 합계: $200 → 200 YES + 200 NO (균형)

A가 이길 경우:
- 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

반환: $1000 ✓ (균형 상태일 때 본전)

적은 유동성 문제

1.4재고 고립 문제

핵심 문제

초기: 시장 A 20% YES / 80% NO
제작자 보유: 200 YES + 200 NO

시간 경과... A가 우승후보가 됨 (80% YES):

트레이더: "A의 YES를 사고 싶어!"
제작자: YES 매도, 행복 😊

트레이더: "A의 NO는 안 사, A가 이길 거니까!"
제작자: NO 매도 불가, 고립됨 😰

결과:
- YES: 200 → 50 (150개 매도, 좋음!)
- NO: 200 → 200 (아무도 안 삼, 고립!)

A가 이길 경우:
- 50 YES × $1 = $50
- 200 NO × $0 = $0
제작자 시작 $200, 종료 $50
손실: $150 ❌

왜 교차 시장 매도가 도움이 안 되는가

패배하는 시장(B, C, D, E)에서 NO를 파는 것은 보상이 되지 않습니다:

B의 200 NO를 95¢에 매도 = $190 수취
하지만: A가 이기면, 구매자는 200 × $1 = $200를 받음

제작자는 $200 가치를 $190에 매도 = 손실

교차 시장 매도는 보상이 아니라 더 많은 손실을 추가합니다.

CTF가 이를 해결함

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

상대방 불필요!
언제든지 병합을 통해 탈출 가능.
재고 고립 문제 없음.

LP를 위한 최악의 시나리오

1.5마켓 메이커 (MM)

MM이 수익을 내는 방법

MM 주문 게시:
YES 매수 @ 49¢
YES 매도 @ 51¢

양쪽이 체결될 때:
- 트레이더 A가 YES 매수 @ 51¢ → MM 51¢ 수취
- 트레이더 B가 YES 매도 @ 49¢ → MM 49¢ 지불

MM 수익: 51¢ - 49¢ = 주당 2¢
10,000주 거래 시: 수익 = 

Taker (주문 체결자): 2% 수수료 지불
Maker (주문 제공자): 0.5% 리베이트 수취

MM은 항상 주문을 제공함 → 모든 거래에서
리베이트 획득

가격이 오르는 중?
→ 매수 주문 취소 (비싸게 사는 것 방지)
→ 매도 가격 인상 (더 비싸게 팔기)

아마추어 LP: 매시간 업데이트 → 손해 봄
프로 MM: 매초 업데이트 → 스프레드 포착

상관관계가 있는 시장:
- "Chiefs 슈퍼볼 우승" (YES @ 25¢)
- "Mahomes MVP 수상" (YES @ 30¢)

MM은 Chiefs YES 매도, Mahomes YES 매수 (헤지)
순 노출: ~0
하지만: 스프레드 수익은 유지!

MM 수익 공식

MM 수익 = 스프레드 수입
          + 수수료 리베이트
          + 차익거래 이익
          - 재고 손실
          - 운영 비용

Nostra에 MM을 유치하는 방법

핵심 통찰: Polymarket 모델

유동성 미러링 (Bridge Market Maker)

1.6수수료 구조

제안된 수수료 구조

트레이드오프

수수료가 손실을 커버할 수 있는가?

업계 벤치마크 (Industry Benchmarks)

수수료 분배 모델

1.7AMM vs 오더북

근본적인 차이점

왜 오더북인가?

1.8공유 유동성 프로토콜

유동성 레이어로서의 Nostra

생태계 이점

공유 유동성 레이어를 구축함으로써 다음이 가능해집니다:

• 어떤 UI든 가능: 개발자는 자체 유동성을 부트스트랩할 필요 없이 Nostra 위에 자신만의 베팅 인터페이스를 구축할 수 있습니다.
• 트레이딩 봇: MM과 차익거래 봇이 스마트 컨트랙트와 직접 상호작용하여 효율성을 보장합니다.
• 네트워크 효과: 새로운 통합이 이루어질 때마다 모든 참여자를 위한 유동성이 강화됩니다.

1.9플랫폼 경제학

수익 모델

• 1
  거래 수수료 모든 거래의 2% (LP와 공유)
• 2
  상환 수수료 당첨금 수령 시 1% (선택 사항)
• 3
  시장 생성 비용 스팸 방지를 위한 소액의 비용

1.10구현 고려사항

초기 런칭 전략

1.11소수점 정밀도와 더스트(Dust)

고정소수점 연산이 예측 시장의 토큰 계산에 어떤 영향을 미치는지 이해합니다.

정밀도 문제

// 수학적 계산
$10 / $0.55 = 18.181818181818181818... (무한 반복)

// 18자리 소수점 정밀도 (블록체인 한계)
저장값: 18.181818181818181818 (잘림)

// 역으로 곱해서 검증
18.181818181818181818 × $0.55 = $9.99999999999999999990

// "더스트"
$10.00000000000000000000
-$9.99999999999999999990
─────────────────────────
 $0.00000000000000000010  ← 정밀도 손실 (~0.00000000000000001 센트)

더스트는 어디로 가는가?

CTFExchange에서 컨트랙트는 정수 나눗셈을 사용하며 항상 내림(round DOWN)합니다:

// CTFExchange 컨트랙트 - 더스트가 여기에 누적됨
mapping(address => uint256) public balances;

실질적 영향

2.1시장 모델 비교 개요

다중 결과 예측 시장을 위한 두 가지 주요 시장 모델 아키텍처를 이해합니다: Nostra의 현재 Grouped Binary 방식 vs Polymarket의 NegRisk 어댑터 솔루션.

2.2Grouped Binary 모델 (Nostra)

Grouped Binary 모델은 Nostra의 현재 구현입니다. 다중 결과 질문의 각 결과는 독립적인 바이너리 시장으로 취급되며 자체 YES/NO 토큰을 가집니다.

작동 방식

주요 특성

재고 고립 문제

2.3Nostra의 유동성 문제 상황

Nostra의 Grouped Binary 모델은 단순하지만, 다중 결과 마켓에서 심각한 유동성 문제가 발생합니다. 실제 시나리오를 통해 어떤 상황에서 문제가 생기는지 살펴보겠습니다.

📌 시나리오 설정: 2026 월드컵 우승팀 예측

🔴 문제 상황 1: Stuck Inventory (포지션 전환 불가)

// Alice의 초기 투자
구매: Spain YES 1,000개 @ 20¢
투자금: $200
예상 수익: Spain 우승 시 $1,000 (5배)

// 1주일 후: Spain이 조별리그에서 탈락!
Spain YES 가격: 20¢ → 3¢ (85% 하락)
Alice의 포지션 가치: $200 → $30

Alice는 이제 France가 우승할 것 같아서 포지션을 바꾸고 싶습니다:

// Step 1: Spain YES 매도
매도: 1,000개 @ 3¢
받는 금액: $30
슬리피지: -10% → 실제 $27

// Step 2: France YES 매수
France YES 가격: 25¢
구매 가능: $27 / 0.25 = 108개
슬리피지: +8% → 실제 100개

결과: 1,000개 → 100개 (90% 손실)

// Direct Conversion via Adapter
Spain YES → France YES
수학적 변환 (슬리피지 없음)

가치 기준 변환:
$30 가치 → $30 가치
France @ 25¢ = 120개

결과: 가치 보존, 20% 더 많은 토큰

🔴 문제 상황 2: 유동성 분산 (Liquidity Fragmentation)

// Nostra 오더북 상태 (Brazil YES)
총 마켓 유동성: $50,000 (5개 팀 전체)
Brazil 마켓 유동성: $10,000 (1/5)

오더북 깊이:
  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)
─────────────────────────────
  총 깊이: ~$10,230

// Bob이 $10,000 시장가 주문 실행
$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
─────────────────────────────
총: 56,789 shares @ 평균 17.6¢

기대 가격 (15¢)으로 샀다면: 66,667 shares
슬리피지 손실: ~15% (9,878 shares)

🔴 문제 상황 3: 가격 불일치 (Price Inconsistency)

독립된 마켓이기 때문에 모든 YES 가격의 합이 100%가 되지 않을 수 있습니다:

🔴 문제 상황 4: LP 재고 리스크

// Charlie가 Spain 마켓에 유동성 제공
제공: YES 측 $5,000, NO 측 $5,000 (총 $10,000)

// 거래 발생: 사용자들이 Spain YES를 대량 매수
결과: Charlie는 Spain YES를 팔고 USDC를 받음
포지션: Spain NO $8,000 보유 (편향된 재고)

// Spain 탈락 후
Spain NO = $1 (승리!)
Charlie 수익: +$8,000

// 하지만 Spain이 우승했다면?
Spain NO = $0 (패배)
Charlie 손실: -$8,000

문제: 재고를 다른 팀으로 전환할 수 없음!
Charlie가 France NO로 헤지하고 싶어도:
1. Spain NO 매도 (슬리피지)
2. France NO 매수 (슬리피지)
= 이중 슬리피지로 헤지 비용 과다

📊 문제 요약: Nostra vs Polymarket

2.4NegRisk 어댑터 (Polymarket 방식)

핵심 아이디어: 담보가 상호 배타적인 YES 토큰들로 직접 분할됩니다. 이를 통해 유동성이 집중됩니다.

실전 예시: $10,000 유동성, 5개 국가

5개 국가: Spain, Brazil, France, Argentina, England

초기 가격: 각 20¢ YES / 80¢ NO (20% 확률)
마켓 메이커: 국가당 $2,000 공급 → 2,000 (YES+NO) 쌍씩
총 유동성: $10,000

// 거래 6: Spain YES $100 추가 매수
Spain YES 500개만 남음
가격 급등: 20¢ → 30¢ → 40¢
$100로 250개만 매수 가능 (500개가 아님!)

반면: 1,500 Spain NO는 쓸모없이 방치됨 💀

// 마켓 메이커가 과잉 NO를 변환
5개 국가에서 각 200 NO 수집
= 200개의 완전한 NO 세트 (5개 토큰씩)
= 200 × $4 = $800 USDC로 환원!

→ 400개의 새 Spain YES+NO 쌍 발행

결과 비교

2.5NegRisk 아키텍처

아키텍처 레이어

주요 컨트랙트

2.6구현 옵션

Nostra가 NegRisk를 구현하기 위해 필요한 것

• 1
  WrappedCollateral.sol 내부 회계를 위한 USDC의 ERC20 래퍼
  쉬움
• 2
  NegRiskAdapter.sol 핵심 변환 로직: splitPosition, mergePositions, convertPosition
  어려움
• 3
  NegRiskOperator.sol 시장 그룹 관리, 바이너리 시장 연결
  중간
• 4
  데이터베이스: negRiskMarketId 필드 같은 그룹의 시장 연결
  쉬움
• 5
  API: /api/negrisk/convert 엔드포인트 프론트엔드의 변환 요청 처리
  중간
• 6
  프론트엔드: 포지션 변환 UI 같은 그룹 내 결과 간 변환 버튼
  중간

예상 소요 시간

3.1오라클 전략 및 비교

Nostra는 암호화폐 가격부터 틈새 지역 이벤트까지 다양한 시장 유형을 처리하기 위해 멀티 오라클 전략을 채택합니다. 우리는 하이브리드 AI와 낙관적 오라클을 사용하는 Opinion Labs 및 UMA를 사용하는 Polymarket과 같은 업계 선두주자들을 벤치마킹합니다.

비교 분석: 세 가지 오라클 계층

채택 로드맵: 단계별 진화

3.2낙관적 오라클 (UMA) 통합

검증 가능한 온체인 데이터나 API를 사용할 수 없는 시장(예: "이 유튜버가 구독자 100만 명을 달성할까?" 또는 매우 주관적인 "의견" 시장)의 경우, 우리는 UMA의 낙관적 오라클(Optimistic Oracle)을 활용합니다. 이를 통해 인간이 암호경제학적 보증을 바탕으로 시장을 해결할 수 있습니다.

"낙관적" 메커니즘

해결 호출 흐름 (Call Flow)

하이브리드 구현: Opinion AI + UMA

비정형 시장의 해결을 확장하기 위해, 우리는 Opinion Labs와 유사한 하이브리드 AI 접근 방식을 채택합니다. 이는 AI의 속도와 낙관적 오라클의 보안성을 결합한 것입니다.

3.3OptimisticOracleV3 사양

OptimisticOracleV3는 주장(assertion) 수명 주기를 관리하는 핵심 컨트랙트입니다. 이는 이의가 제기되지 않는 한 진실로 간주되는 에스컬레이션 게임(escalation game)을 활용합니다.

핵심 함수 (Key Functions)

// Core OOv3 Interface
interface IOptimisticOracleV3 {
    /**
     * @notice 세계 상태에 대한 진실을 주장합니다.
     * @param claim 진술을 나타내는 인코딩된 데이터 또는 문자열 (예: "BTC > 50k at block 100").
     * @param asserter 정답일 경우 채권을 돌려받을 주소.
     * @param callbackRecipient 정산 시 알림을 받을 주소.
     * @return assertionId 이 주장의 고유 ID.
     */
    function assertTruthWithDefaults(
        bytes calldata claim,
        address asserter
    ) external returns (bytes32 assertionId);

    /**
     * @notice 주장을 정산합니다. 활동 기간(Liveness Period) 이후에만 호출 가능합니다.
     * @return bool 주장이 '진실'로 해결되었으면 true를 반환합니다.
     */
    function settleAndGetAssertionResult(bytes32 assertionId) external returns (bool);

    /**
     * @notice 상태 확인을 위한 View 함수.
     */
    function getAssertionResult(bytes32 assertionId) external view returns (bool);
}

Nostra 통합 로직

• 주장 (Assertion): 우리는 assertTruthWithDefaults를 호출합니다. 이는 주장자로부터 최소 채권(Minimum Bond)(보통 WETH 또는 USDC)을 예치하게 합니다.
• 활동 기간 (Liveness Period): 기본값은 7200초(2시간)입니다. 이 기간 동안 모든 봇은 `disputeAssertion`을 호출할 수 있습니다.
• 정산 (Settlement): 이의 없이 기간이 종료되면, 우리는 settleAndGetAssertionResult를 호출합니다. true가 반환되면 Nostra는 승자에게 지급을 처리합니다.

이의 제기 흐름 (Dispute Flow)

• 모니터링 (Monitoring): 감시견(Watchdog) 봇이 실제 데이터와 주장을 대조하여 검증합니다.
• 이의 제기 (Challenge): 불일치가 발견되면, 봇은 disputeAssertion을 호출합니다. 이 경우 판결은 UMA의 데이터 검증 메커니즘(DVM)으로 넘어갑니다.
• DVM 투표 (DVM Voting): UMA 토큰 보유자들이 특정 진실에 대해 투표합니다.
• 보상 (Reward): 이의 제기가 타당했다면, 도전자(Challenger)는 주장자(Asserter)의 채권을 포상금으로 받습니다.

3.4체인링크 시작하기

체인링크를 통합하려면 다음 단계가 필요합니다:

1. LINK 토큰 확보: 오라클 서비스 비용 지불을 위해 필요합니다.
2. 구독 생성: Chainlink Functions 또는 Automation을 위한 구독을 생성하고 LINK를 충전합니다.
3. 컨트랙트 등록: Consumer 컨트랙트를 구독에 추가합니다.

3.4체인링크 제품 개요

노드 → 집계 → 온체인
       ↓
컨트랙트가 가격 읽기
       ↓
비교 → 해결

컨트랙트 → 요청 → DON
       ↓
자바스크립트 실행
       ↓
API 조회 → 반환

Upkeep 등록 → 모니터링
       ↓
조건 충족?
       ↓
performUpkeep()

3.5해결 아키텍처

현재 vs 제안된 흐름

3.6스마트 컨트랙트 통합

Functions 클라이언트 예시 (요청)

// FunctionsClient.sol (우리 마켓 컨트랙트가 상속)
import { FunctionsClient } from "@chainlink/.../FunctionsClient.sol";
import { FunctionsRequest } from "@chainlink/.../FunctionsRequest.sol";

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

    address router = 0x...; // 체인링크 라우터 (오라클 컨트랙트)
    bytes32 donId = 0x...;  // DON ID (네트워크 식별자)
    uint64 subscriptionId = 1234; // 내 구독 ID (결제 계정)

    // 이 함수가 체인링크 라우터 컨트랙트를 호출합니다
    function resolveMarket() external {
        
        // 1. 요청서 작성 (JavaScript 로직 포함)
        FunctionsRequest.Request memory req;
        req.initializeRequestForInlineJavaScript("const apiResponse = await Functions.makeHttpRequest(...)");

        // 2. 체인링크 라우터로 전송 (그림의 Step 1 화살표)
        bytes32 requestId = _sendRequest(
            req.encodeCBOR(),
            subscriptionId,
            gasLimit,
            donId
        );
        
        // 3. 요청 ID 저장 (나증에 검증용)
        pendingRequests[requestId] = true;
    }
}
            

Price Feed Resolver 예시

// 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;      // 8자리 소수점 가격 임계값
        bool resolveAbove;      // true = 가격 > 임계값이면 YES 승리
        uint256 deadline;
        bool resolved;
    }

    mapping(bytes32 => PriceMarket) public markets;

    function resolveMarket(bytes32 questionId) external {
        PriceMarket storage market = markets[questionId];
        require("이미 해결됨");
        require(block.timestamp >= market.deadline, "너무 이름");

        // 체인링크에서 최신 가격 가져오기
        (, int256 price, , , ) = priceFeed.latestRoundData();

        // 승자 결정
        bool yesWins = market.resolveAbove
            ? price > int256(market.threshold)
            : price < int256(market.threshold);

        // CTF에 배당 보고
        uint256[] memory payouts = new uint256[](2);
        payouts[0] = yesWins ? 1 : 0;  // YES 결과
        payouts[1] = yesWins ? 0 : 1;  // NO 결과

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

Chainlink Functions 예시 (JavaScript)

// 이 코드는 Chainlink Functions DON에서 실행됩니다
const apiEndpoint = args[0];  // 예: "https://api.sportsdata.io/..."\
const jsonPath = args[1];     // 예: "Games[0].Winner"

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

if (response.error) {
  throw Error("API 요청 실패");
}

// JSON 경로 탐색 및 결과 반환
const homeTeamWins = result === "HomeTeam" ? 1 : 0;
return Functions.encodeUint256(homeTeamWins);
            

네트워크 주소

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

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

3.7비용 및 보안 고려사항

월간 비용 추정 (시장 100개 기준)

보안 고려사항

4.1배포 네트워크

전략적 우선순위

배치 처리에서 가스비의 중요성 (UX 핵심)

최적의 UX를 제공하기 위해, 우리 서버는 사용자 작업을 배치 처리(Batch Processing)할 가능성이 높습니다 (예: 50개의 주문을 하나의 트랜잭션으로 매칭). 이렇게 하면 사용자에게 즉각적인 확인과 가스비 없는 경험을 제공할 수 있지만, 가스비는 플랫폼의 직접적인 운영 비용이 됩니다.

결론: 만약 우리가 가스비를 대납하거나 배치 프로세서를 운영한다면, Arbitrum과 같은 L2는 현재 규모에서 너무 비쌉니다. 경제적 생존을 위해 Polygon 또는 BSC는 필수입니다.

비교 분석: L1 vs L2

주요 권장 사항: BNB 스마트 체인 (BSC)

Polygon은 낮은 수수료 덕분에 여전히 실행 가능한 백업이지만, BSC의 압도적인 퍼포먼스와 전략적 생태계 연계는 Nostra를 위한 최적의 런치패드가 됩니다.

4.2브릿징 전략 (CCIP)

왜 브릿지인가?

해결책: 체인링크 CCIP (상호운용성 프로토콜)

CCIP를 사용하면 지원되는 어느 체인에서든 입금을 받고 이를 우리의 특정 시장 구현으로 라우팅할 수 있습니다.

통합 아키텍처

CCIP의 이점

• 통합된 유동성: 모든 체인의 사용자를 마치 하나의 체인에 있는 것처럼 취급합니다.
• 단순화된 UX: 하나의 트랜잭션으로 "입금 및 베팅" (브릿징 과정 추상화).
• 보안: 위험 관리 네트워크(RMN, 2차 검증)가 일반적인 브릿지 해킹을 방지합니다.

5.1시장 생성 프로세스 (내부 동작 원리)

"가스비 없는" 생성자 경험

Nostra는 시장 생성자가 블록체인과 직접 상호작용하는 복잡성을 추상화합니다. 사용자가 "배치 생성 시작 (Start Batch Creation)" 버튼을 클릭하면, 서버가 모든 온체인 작업을 비동기적으로 처리합니다.

단계별 실행 내역

상세 토큰 흐름: 유동성 및 시딩 (Liquidity & Seeding)

시장이 즉시 거래 가능하도록 보장하기 위해, 서버 지갑(Server Wallet)이 초기 유동성 공급자 역할을 수행합니다. 이는 다음과 같은 구체적인 토큰 전송 순서를 포함합니다:

5.2청구 프로세스 (이중 확인)

왜 두 번의 트랜잭션이 필요한가요?

사용자들은 종종 당첨금 청구 시 지갑 확인이 두 번 필요한 이유를 묻습니다. 이는 조건부 토큰 프레임워크 (CTF)와 Nostra 거래소 컨트랙트 간의 아키텍처적 분리 때문입니다.

contract.redeemPositions(...)

exchange.deposit(...)

왜 자동으로 입금되지 않나요?

자주 묻는 질문 중 하나는 "왜 상환(Redemption) 단계에서 자금을 거래소로 자동 전송할 수 없는가?"입니다.

• 프로토콜 분리: `redeemPositions` 함수는 표준 Gnosis CTF Core 컨트랙트에 속해 있습니다. 이는 중립적이고 불변하는 기초 요소(primitive)로, 우리의 특정 거래소 컨트랙트에 대해 전혀 알지 못합니다.
• 보안 및 제어: CTF 컨트랙트는 담보를 오직 토큰 보유자에게만 반환하도록 설계되었습니다. 임의로 다른 컨트랙트로 입금을 트리거하도록 강제할 수 없습니다.
• 수동 단계 필요: 따라서 사용자는 먼저 자금을 수령(1단계)한 후, 명시적으로 거래소에 승인/입금(2단계)해야 합니다.