Skip to main content

​
Sidiora Mirroring Spec

This page defines the Phase 1 draft contract between the indexer and backend for Sidiora perpetual trade mirroring, plus the mandatory risk policy enforced by the mirror bot.
Sidiora execution is off-chain first and on-chain settled. This means ZibaXeer must enforce risk controls in off-chain services and treat bot behavior as part of the trusted computing base.

​
Scope

Phase 1 covers:
  • Delegation-based execution via SidioraVaultAdapter.
  • Off-chain mirror orchestration in indexer and backend workers.
  • Risk policy enforcement before signing or forwarding follower orders.
  • Audit logs and failure handling.
Phase 1 does not include:
  • On-chain realized PnL fee splitting from Sidiora internal ledger.
  • Fully trustless per-trade settlement proofs.

​
Trust Model

​
Roles

RoleTrust LevelCapabilitiesHard Constraint
Vault Owner (on-chain)HighConfigure adapter, rotate/revoke mirror delegateCannot bypass onlyOwner controls
Mirror Bot (off-chain signer)MediumSubmit mirrored orders to Sidiora sequencerMust never receive withdrawal permission
IndexerMediumIngest leader intents/events and enqueue mirror jobsCannot directly move vault funds
Backend WorkersMediumRun risk checks and create signed follower intentsMust pass policy validation gate
Sidiora SequencerExternalMatch orders and batch settlementTreated as external dependency/failure domain

​
Security Invariants

  • Delegate permissions must always be: canTrade=true, canWithdraw=false, canModifyMargin=true.
  • Any mirror bot key compromise must be containable via on-chain revokeMirrorBot.
  • Margin deposits and withdrawals remain owner-gated on adapter.
  • No off-chain component can withdraw vault funds through Sidiora delegation.

​
Risk Policy (Mandatory)

Every follower mirror order must pass all checks before submission.
Policy KeyDescriptionExample DefaultAction on Violation
maxLeverageMaximum effective leverage per follower account10x in betaReject order
maxNotionalPerMarketCap notional exposure per market20% of follower equityReject order
maxPortfolioNotionalCap total open notional across all markets60% of follower equityReject order
maxSlippageBpsMax allowed slippage from leader reference quote75 bpsReject order
maxOrderSkewBpsMax proportional size drift from leader ratio30 bpsReject order
minHealthFactorMinimum account health after simulated fill1.20Reject order
cooldownSecondsMinimum time between mirrored entries per follower+market15 secDelay/reject
dailyLossLimitBpsMax daily realized+unrealized loss500 bpsFreeze follower mirroring

​
Policy Evaluation Order

  1. Authenticate leader signal source.
  2. Validate strategy and follower subscription state.
  3. Simulate post-trade state using latest mark/maintenance values.
  4. Apply hard-risk checks (leverage, notional, health).
  5. Apply execution checks (slippage, skew, cooldown).
  6. Sign and enqueue only if all checks pass.

​
Indexer to Backend Contract

ZibaXeer uses queue-based integration rather than direct synchronous HTTP.

​
Queue Names

QueueProducerConsumerPurpose
SidioraMirrorSignalQueueIndexerMirror workerLeader signal intake
SidioraMirrorResultQueueMirror workerAnalytics/ops workerDelivery status + errors
SidioraRiskAlertQueueMirror workerOps/monitoring workerBreach and freeze notifications

​
Message: Leader Mirror Signal (v1)

{
  "version": "1.0",
  "eventType": "LEADER_SIGNAL_RECEIVED",
  "traceId": "uuid",
  "leaderAddress": "0x...",
  "vaultAddress": "0x...",
  "sidioraMarket": "BTC-PERP",
  "side": "LONG",
  "orderType": "MARKET",
  "leaderSize": "125000000",
  "leaderPrice": "64000000000",
  "leaderLeverage": "5000000000000000000",
  "timestamp": 1774451900,
  "source": "sidiora-sequencer"
}

​
Message: Mirror Execution Result (v1)

{
  "version": "1.0",
  "eventType": "MIRROR_EXECUTION_RESULT",
  "traceId": "uuid",
  "vaultAddress": "0x...",
  "leaderAddress": "0x...",
  "followerAddress": "0x...",
  "sidioraAccount": "0x...",
  "status": "ACCEPTED",
  "reason": null,
  "riskSnapshot": {
    "effectiveLeverage": "4.2",
    "healthFactor": "1.56",
    "portfolioNotionalRatio": "0.41"
  },
  "sequencerRequestId": "sidiora-req-id",
  "timestamp": 1774451902
}

​
Retry and Idempotency Rules

  • traceId is globally unique per leader signal and used as idempotency key.
  • Consumers must treat duplicate traceId as no-op after first successful persistence.
  • Retry on transient failures (network, timeout, 429/5xx) with exponential backoff.
  • Do not retry policy failures (status=REJECTED_POLICY).

​
Control Plane API (Backend)

These endpoints are the operator-facing control surface.
EndpointMethodPurpose
/api/sidiora/policyGETRetrieve active policy values and version
/api/sidiora/policyPUTUpdate policy values (admin only)
/api/sidiora/mirroring/statusGETService health, queue lag, and sequencer reachability
/api/sidiora/mirroring/freeze/:vaultPOSTEmergency freeze mirroring for a vault
/api/sidiora/mirroring/unfreeze/:vaultPOSTResume mirroring for a vault

​
Failure Modes and Playbooks

Failure ModeDetectionImmediate ActionRecovery
Sequencer unavailableTimeout/error-rate alarmsPause new submissions, keep consuming signals into dead-letter queueAuto-resume after health checks pass
Mirror bot key compromiseAbnormal signing patterns / key exposureCall revokeMirrorBot on affected adaptersRotate key and rotateMirrorBot
Risk engine driftDivergence between expected vs actual exposureTrigger vault freeze endpoint and emit risk alertsReconcile state and replay safe signals
Queue backlog spikeQueue lag SLO breachedActivate backpressure and lower intake rateHorizontal scale workers and drain queue
Partial follower executionResult mismatch for subset of followersMark failed followers for retry windowRetry where safe, otherwise close exposure

​
Audit Requirements

  • Persist leader signal, normalized follower order, risk decision, and sequencer response per traceId.
  • Emit immutable audit events for policy updates and freeze/unfreeze operations.
  • Keep a deterministic decision log for every rejected order.