시작
개요
NexusSDK가 제공하는 기능과 모든 서비스가 따르는 규칙.
NexusSDK는 ORBITRA ONE™의 개발자 인터페이스입니다. 시장, 신원, 자산, 에이전트 기본 기능을 타입이 지정된 서비스로 제공하며, Orbitra Prime을 구동하고 Orbitra L1에서 결제되는 동일한 네이티브 모듈을 기반으로 합니다.
서비스
- 시장 API — ApexMatch에서 처리하는 주문, 호가창, RFQ, 클리어링 델타이며, 모든 주문에 Aegis 사전 위험 검사가 적용됩니다.
- Asset Studio — 발행자 권한, 생애주기 이벤트, 자격 요건 적용을 갖춘 토큰화 자산의 발행 및 관리.
- 에이전트 신원 — AI 에이전트와 봇을 책임 소재가 있는 신원으로 등록하며, 각각 Cortex 정책에 귀속됩니다.
- 데이터 교환 — 검증 가능한 출처를 갖춘 데이터셋과 신호의 게시 및 라이선싱.
- VaultID — 신원 문서를 다루지 않고 자격 요건과 권한에 대한 자격 증명을 확인합니다.
- 결제 — 거래와 동일한 결정론적 완결성으로 처리되는 결제 요청 및 정산.
설계 원칙
- 모든 호출은 명시적이고 범위가 지정된 권한을 가진 신원을 통해 이루어집니다.
- 모든 상태 변경은 독립적으로 검증할 수 있는 서명된 영수증을 반환합니다.
- 클라이언트에서 설정한 한도는 프로토콜에서 다시 한번 적용됩니다.
- 자격 증명과 엔드포인트는 항상 환경 변수에서 가져오며, 소스 코드에 포함되지 않습니다.
시작
퀵스타트
SDK를 설치하고, 환경 변수로 자격 증명을 구성한 뒤, 최초로 인증된 호출을 실행합니다.
이 샘플의 패키지 및 크레이트 이름은 예시적인 패턴을 따릅니다. 실제 공개된 패키지 이름, 샌드박스 자격 증명, 엔드포인트는 SDK 이용 시 함께 발급됩니다 — 개발자 관심 등록.
설치
NexusSDK 설치
# TypeScript and JavaScript
npm install @orbitra/nexus-sdk
# Python
pip install orbitra-nexus
# Rust
cargo add orbitra-nexus자격 증명 구성
SDK는 두 개의 환경 변수를 읽습니다. 두 값 모두 소스 관리 시스템에 포함하지 말고 시크릿 관리자나 배포 환경에서 불러오세요. 샌드박스 자격 증명으로 시작하세요. 샌드박스는 실제 자산 및 시장과 분리되어 있습니다.
- ORBITRA_API_KEY — SDK 이용 시 발급되는 범위가 지정된 자격 증명입니다.
- ORBITRA_ENDPOINT — 해당 자격 증명과 함께 발급되는 환경 엔드포인트입니다.
환경 변수 설정
# Both values are issued with SDK access. Never commit them to a repository.
export ORBITRA_API_KEY="<issued-with-sdk-access>"
export ORBITRA_ENDPOINT="<issued-with-sdk-access>"첫 호출
현재 계정 조회
import { NexusClient } from '@orbitra/nexus-sdk';
const apiKey = process.env.ORBITRA_API_KEY;
const endpoint = process.env.ORBITRA_ENDPOINT;
if (!apiKey || !endpoint) {
throw new Error('Set ORBITRA_API_KEY and ORBITRA_ENDPOINT before running this example.');
}
const nexus = new NexusClient({ apiKey, endpoint });
const account = await nexus.accounts.current();
console.log(account.id, account.permissions);응답은 해당 자격 증명 뒤에 있는 계정을 설명합니다. VaultID 자격 증명, 이 키에 부여된 권한, 접근 가능한 시장이 포함됩니다. 권한 오류가 발생하면 키는 유효하지만 해당 작업에 대한 범위가 지정되지 않았다는 의미입니다. 이후 샘플에서는 동일한 두 변수를 읽는 축약형 NexusClient.fromEnv()를 사용합니다.
개념
계정과 VaultID
개인, 기관, 애플리케이션, 에이전트를 위한 신원, 자격 증명, 범위가 지정된 권한.
VaultID는 신원, 자격 요건, 권한 계층입니다. 모든 호출자, 즉 개인, 기관, 애플리케이션, 에이전트는 자격 증명을 보유한 신원을 통해 행동합니다. 애플리케이션은 자격 증명을 확인할 뿐, 그 뒤에 있는 문서를 받지 않습니다.
신원 유형
- 개인 — 온보딩 과정에서 발급된 자격 요건 증명을 보유한 사람.
- 기관 — 하위 계정, 역할, 2인 승인 규칙을 갖춘 조직.
- 애플리케이션 — 개발자가 등록한 서비스로, 선언한 권한만 보유합니다.
- 에이전트 — Cortex 정책에 귀속되며 소유자가 철회할 수 있는 AI 에이전트 또는 봇.
범위가 지정된 키
API 키는 어떤 서비스, 어떤 시장, 어떤 작업에 얼마 동안 사용할 수 있는지를 정하는 범위와 함께 신원에 발급됩니다. 환경과 애플리케이션마다 별도의 키를 사용하고, 더 이상 필요하지 않은 키는 철회하세요.
기능을 활성화하기 전에 자격 증명 확인
import { NexusClient } from '@orbitra/nexus-sdk';
const nexus = NexusClient.fromEnv();
export async function canTradeOptions(subjectId: string): Promise<boolean> {
// Returns whether the credential is present and valid, never the data behind it.
const result = await nexus.vaultid.verify({
subject: subjectId,
credential: 'eligibility.options',
});
return result.valid;
}자격 요건 확인을 재현하기 위해 애플리케이션에서 신원 문서를 수집하지 마세요. 대신 자격 증명을 요청하세요. VaultID는 자격 증명의 존재 여부와 유효성만 확인해 줍니다.
개념
증거와 완결성
영수증에 담긴 내용, 상태 변경이 완결되는 시점, 이 둘을 검증하는 방법.
상태를 변경하는 모든 호출은 영수증을 반환합니다. 이는 네트워크가 요청을 어떻게 처리했는지에 대한 서명된 기록으로, 수신 시점, 시퀀싱된 위치, Aegis의 판단, 그 결과로 변경된 사항을 담고 있습니다.
영수증 구성 요소
- 수신 — 요청을 수락한 게이트웨이의 유입 타임스탬프와 서명.
- 시퀀스 — 공정한 시퀀싱을 통해 부여된 정규 위치.
- 위험 판정 — Aegis의 결정이며, 거부된 경우에는 위반되었을 한도를 포함합니다.
- 결과 — 전환에 따라 발생한 체결, 클리어링 델타, 계약 이벤트 또는 이전 내역.
- 완결성 — 전환이 완결되면 부여되는 QSE 쿼럼 인증서에 대한 참조.
전환은 QSE 쿼럼 인증서가 적용되는 시점에 완결됩니다. 별도의 확인 깊이를 기다릴 필요는 없습니다. 인증이 완료되면 명시된 장애 모델 하에서 상태가 재구성되지 않습니다.
완결을 기다리고 인증서 검증하기
import { NexusClient } from '@orbitra/nexus-sdk';
const nexus = NexusClient.fromEnv();
export async function confirmFinal(transitionId: string): Promise<boolean> {
// Resolves once a QSE quorum certificate covers the transition.
const finality = await nexus.finality.wait(transitionId);
// Checks the certificate signatures locally against the validator set it names.
const verified = await nexus.finality.verify(finality.certificate);
return finality.status === 'final' && verified;
}빌드
시장 API와 ApexMatch 주문
TypeScript, Python, Rust로 클라이언트 측 정책에 따라 포스트온리 리밋 주문을 실행합니다.
시장 API는 ApexMatch를 직접 노출합니다. 주문은 서명된 의도입니다. SDK가 귀하의 키로 서명하고, 게이트웨이가 서명을 검증하며, 공정한 시퀀싱이 위치를 부여하고, 주문이 호가창에 도달하기 전에 Aegis 사전 위험 검사가 실행됩니다.
클라이언트 측 정책은 두 번째 보호 장치를 추가합니다. SDK는 서명 전에 이를 평가하므로, 자체 한도를 벗어난 주문은 프로세스를 벗어나지 않습니다. Aegis는 프로토콜 게이트에서 계정 수준의 한도를 별도로 적용합니다.
클라이언트 측 정책에 따라 리밋 주문 실행
import { NexusClient, definePolicy } from '@orbitra/nexus-sdk';
// fromEnv() reads ORBITRA_API_KEY and ORBITRA_ENDPOINT.
const nexus = NexusClient.fromEnv();
// Evaluated locally before the order is signed.
// Aegis enforces account-level limits again at the protocol gate.
const policy = definePolicy({
markets: { allow: ['EURUSD'] },
maxOrderNotional: '50000',
maxLeverage: 2,
requirePostOnly: true,
});
const receipt = await nexus.orders.place(
{
market: 'EURUSD',
side: 'buy',
type: 'limit',
price: '1.0850',
size: '10000',
postOnly: true,
clientOrderId: 'docs-example-001',
},
{ policy },
);
console.log(receipt.status, receipt.sequence, receipt.riskVerdict);주문 유형
마켓, 리밋, 스톱, 스톱리밋, 포스트온리, 리듀스온리와 같은 핵심 유형은 네이티브로 지원됩니다. 고급, 알고리즘, 기관용 유형은 동일한 기본 기능을 조합해 구성되며, 전체 주문 유형은 체결에서 설명합니다.
이 샘플의 시장 식별자, 가격, 수량은 예시입니다. API를 통한 시장 접근에는 인터페이스와 동일한 자격 요건 및 관할 지역 규칙이 적용됩니다.
빌드
위험 관리와 Aegis 시뮬레이션
자본을 투입하기 전에 거래 후 포트폴리오와 스트레스 시나리오를 시뮬레이션합니다.
Aegis는 사전 위험 게이트에서 실행하는 것과 동일한 시뮬레이션을 제공합니다. 제안된 주문과 원하는 스트레스 시나리오를 전송하면, 아무것도 제출하지 않은 상태로 Aegis가 예상 포트폴리오 상태와 주문이 위반할 수 있는 정책을 반환합니다.
실행 전 시뮬레이션
import { NexusClient } from '@orbitra/nexus-sdk';
const nexus = NexusClient.fromEnv();
// Nothing is submitted: Aegis returns the projected post-trade state.
const simulation = await nexus.risk.simulate({
orders: [
{ market: 'EURUSD', side: 'buy', type: 'limit', price: '1.0850', size: '10000' },
],
scenarios: ['volatility-shock', 'liquidity-drain'],
});
console.log('margin used', simulation.marginUsed);
console.log('liquidation distance', simulation.liquidationDistance);
for (const breach of simulation.policyBreaches) {
console.warn(breach.policy, breach.limit, breach.projected);
}시뮬레이션이 반환하는 정보
- 제안된 주문 이후 예상 증거금 사용량과 여유 담보.
- 주문이 영향을 미치는 모든 포지션의 청산까지의 거리.
- 요청한 각 스트레스 시나리오에 대한 결과.
- 한도와 예상 값을 포함한 각 정책 위반 내역.
시뮬레이션은 요청 시점의 포트폴리오 상태를 나타냅니다. 시장은 계속 움직이므로, 시뮬레이션이 동일한 값으로 주문이 접수되거나 체결된다는 것을 보장하지는 않습니다.
빌드
에이전트와 Cortex 정책
에이전트 신원을 등록하고 한도와 긴급 중지 기능을 갖춘 명시적 정책에 귀속시킵니다.
에이전트는 그 자체로 하나의 신원입니다. 시장을 폭넓게 관찰할 수 있지만, 배분할 수 있는 자본, 감당할 수 있는 손실, 사용할 수 있는 레버리지·시장·시간, 사람의 확인이 필요한 시점, 의존할 수 있는 데이터 소스를 규정하는 Cortex 정책 안에서만 행동합니다.
에이전트가 제안하는 모든 의도는 관찰, 추론, 제안, 시뮬레이션, 승인, 실행이라는 Cortex 루프를 거칩니다. 정책 엔진이 각각을 승인 또는 거부하며, 모든 행동은 해당 에이전트에게 귀속되는 영수증을 생성합니다.
Cortex 정책
{
"policyVersion": "1",
"capital": { "maxAllocation": "100000", "asset": "USD" },
"loss": { "dailyLimit": "2000", "lifetimeLimit": "10000" },
"leverage": { "ceiling": 3 },
"markets": { "allow": ["EURUSD", "GBPUSD"], "deny": [] },
"session": { "hours": "Mon-Fri 07:00-17:00 UTC", "expiresAfter": "P30D" },
"confirmation": { "requiredAboveNotional": "25000" },
"dataSources": ["prism:fx-majors", "account:portfolio"],
"kill": { "onBreach": "revoke-all", "cancelOpenOrders": true }
}에이전트 등록 및 정책 연결
import { readFile } from 'node:fs/promises';
import { NexusClient } from '@orbitra/nexus-sdk';
const nexus = NexusClient.fromEnv();
const policy = JSON.parse(await readFile('./policies/fx-hedger.json', 'utf8'));
const agent = await nexus.agents.register({ name: 'fx-hedger', policy });
// At any time, one command revokes every permission the agent holds.
await nexus.agents.kill(agent.id);에이전트 중지
긴급 중지 기능은 한 번의 명령으로 에이전트가 보유한 모든 권한을 철회합니다. 정책에 명시된 대로 미체결 주문이 취소되며, 이후 에이전트의 키로는 서명할 수 없습니다.
AI 기반 자동화를 포함한 자동화는 오작동하거나 예상치 못하게 동작할 수 있습니다. 정책은 피해 범위를 제한할 뿐, 위험 자체를 없애지는 않습니다. AI 및 자동매매를 참고하세요.
빌드
NexusWASM 계약
Rust로 기능 권한이 지정된 계약을 작성해 네이티브 시장 기본 기능을 호출합니다.
NexusWASM 계약은 WebAssembly로 컴파일되어 계량형 샌드박스에서 실행됩니다. 계약은 자신의 기능 권한, 즉 호출할 수 있는 기본 기능과 접근할 수 있는 상태를 선언하며, 런타임은 이 선언을 벗어난 호출을 거부합니다.
기능 권한이 지정된 트레저리 계약
use orbitra_nexus_wasm::prelude::*;
use orbitra_nexus_wasm::market::{LimitOrder, MarketId, OrderReceipt, Side};
/// Rebalances a treasury position with post-only limit orders on one market.
/// The capability list is checked at deployment; any other call is rejected at runtime.
#[contract(capabilities = [market::place_order, market::cancel_order, storage::read_write])]
pub struct TreasuryRebalancer {
market: MarketId,
max_order_size: Decimal,
}
#[contract_impl]
impl TreasuryRebalancer {
#[call(owner_only)]
pub fn rebalance(
&mut self,
ctx: &mut Context,
side: Side,
price: Decimal,
size: Decimal,
) -> Result<OrderReceipt> {
ensure!(size <= self.max_order_size, ContractError::SizeAboveLimit);
let order = LimitOrder::new(self.market.clone(), side, price, size).post_only(true);
// Native call into ApexMatch. Aegis pre-risk applies to the contract's own account.
ctx.market().place_order(order)
}
}빌드
WebAssembly로 컴파일
rustup target add wasm32-unknown-unknown
cargo build --release --target wasm32-unknown-unknown- 연산과 저장은 명시적으로 가격이 책정되므로, 계약의 비용은 실제로 수행하는 작업에 따라 결정됩니다.
- 선언된 상태 접근 범위 덕분에 독립적인 계약들이 VectorLanes에서 병렬로 실행될 수 있습니다.
- 계약에서 발생하는 시장 호출은 다른 주문과 마찬가지로 계약 자신의 계정에 대해 Aegis 사전 위험 검사를 통과합니다.
- 배포 시에는 모듈을 기능 권한 목록과 함께 제출하며, 선언되지 않은 기본 기능을 호출하는 모듈은 거부됩니다.
빌드
EVM Capsule 이전 경로
기존 EVM 계약을 격리된 환경에서 실행한 뒤, 중요한 경로를 NexusWASM으로 이전합니다.
EVM Capsule은 Ethereum 바이트코드와 도구를 위한 격리된 호환성 영역입니다. 자체적인 가스 및 자원 상한을 가지고 있으며, 핵심 자산에는 속도 제한이 있는 게이트웨이를 통해서만 접근하고, 핵심 런타임에 영향을 주지 않고 서킷 브레이커로 정지시킬 수 있습니다.
캡슐은 핵심 실행 환경이 아니라 호환성 경계입니다. 네이티브 시장 기본 기능은 NexusWASM에서 호출되며, 캡슐은 통제된 게이트웨이를 통해서만 핵심 자산에 연결됩니다.
이전 단계
- 변경 없이 배포. 기존 계약과 익숙한 도구가 캡슐 내부에서 자체 상한에 따라 계량되어 실행됩니다.
- 신중하게 브리지. 익스포저 규모에 맞춘 경로 한도와 함께, 속도 제한이 있는 게이트웨이를 통해 자산을 이동합니다.
- 측정. 네이티브 성능이나 시장 접근이 가장 중요한 지점, 일반적으로 주문 처리, 결제, 위험 관리 로직을 파악합니다.
- 포팅. 해당 경로를 ApexMatch와 Aegis를 직접 호출하는 NexusWASM 계약으로 다시 구현하고, 캡슐 버전은 참조용으로 유지합니다.
- 검증 및 폐기. 동일한 입력을 두 버전 모두에 재현해 실행하고, 결과가 일치하면 사용자를 네이티브 계약으로 이전한 뒤 캡슐 배포를 단계적으로 종료합니다.
운영
검증자와 노드 도구
릴리스를 검증하고, 환경 변수로 노드를 구성하며, 임무를 확인합니다.
운영자는 노드 클라이언트를 실행해 완결된 상태를 재현하고, 애플리케이션에 서비스를 제공하며, 검증자로 승인된 이후에는 QSE 하에서 제안자 및 위원회 임무를 수행합니다. 하나의 클라이언트가 각 역할을 담당하며, 구성은 환경 변수에서 가져오고 서명 키는 HSM 또는 MPC 서명 장치에 보관됩니다.
노드 검증, 구성, 상태 확인
# Verify the release before installing it. Release-signing keys are published with operator access.
orbitra-node verify-release ./orbitra-node.tar.gz --signature ./orbitra-node.tar.gz.sig
# Configuration comes from the environment. Keys stay in the HSM or MPC signer.
export ORBITRA_NETWORK="<issued-with-operator-access>"
export ORBITRA_ENDPOINT="<issued-with-operator-access>"
export ORBITRA_SIGNER="hsm" # or "mpc"
orbitra-node init --network "$ORBITRA_NETWORK" --signer "$ORBITRA_SIGNER"
orbitra-node start
# Inspect assigned duties, quorum participation and service measurements.
orbitra-node status --duties --service
# Rehearse a Q-Switch signature-suite rotation without applying it.
orbitra-node keys rotate --suite next --dry-run표시된 명령어 이름은 예시입니다. 운영자 클라이언트, 릴리스 서명 키, 네트워크 식별자는 운영자 권한과 함께 발급됩니다 — 검증자를 참고하세요.
운영 규칙
- 설치 또는 업그레이드 전에 모든 릴리스 서명을 검증하세요.
- 키는 파일이 아니라 서명 장치를 통해 참조하세요. 검증자 키는 노드 호스트에 두어서는 안 됩니다.
- 임무 및 서비스 측정값을 자체 모니터링 및 경보 시스템으로 내보내세요.
- 임의로 키를 재발급하지 말고 Q-Switch 명령을 통해 서명 스위트를 순환시키세요.
운영
변경 이력
릴리스 노트가 게시되는 방식과 각 노트에 기록되는 내용.
릴리스 노트는 각 NexusSDK 버전과 함께 제공되며, 해당 버전의 문서와 함께 이 게이트웨이에 게시됩니다. 버전 선택기에서 현재 보고 있는 에디션을 확인할 수 있습니다.
모든 릴리스 노트에 기록되는 내용
- 새로 추가, 변경, 제거된 인터페이스와 각 새 형태의 예시.
- 지원 종료 예정 항목, 각각의 대체 방법, 이전 절차.
- Q-Switch를 통해 도입되는 서명 스위트 또는 자격 증명 형식의 변경 사항.
- 노드 운영자와 검증자에게 영향을 미치는 프로토콜 매개변수.
- 공개 절차가 조율된 이후의 보안 수정 사항.
현재 보고 있는 문서는 프리뷰 에디션입니다. 여기에 문서화된 인터페이스는 설계된 사양이며 일반 공개 전까지 변경될 수 있습니다. 모든 변경 사항은 해당 변경을 도입한 버전의 릴리스 노트에 기록됩니다.