Skip to main content

Introduction

Ascend is a fully verifiable events perpetuals decentralized exchange enabling leveraged trading on outcome probabilities. Ascend supports Cardano, EVM, and Solana environments, while enforcing all trading, risk, account, and settlement logic within Midnight, a Cardano partnerchain with multi-resource consensus and native privacy. Ascend inspires from Midnight’s Minotaur philosophy for multichain DeFi execution, privacy focused, policy-driven model to:
  • Order execution
  • Margin and leverage enforcement
  • Liquidation logic
  • Event settlement
This allows execution rights, capital, risk, and permissions to be treated as distinct yet composable resources, all enforced under zero-knowledge guarantees. Ascend adopts a ZK-enforced execution architecture, where all user actions are finalized on Midnight. The architecture is designed to:
  • Maximize throughput
  • Preserve user privacy
  • Provide cryptographic guarantees of correctness
  • Maintain a single canonical execution state
Ascend Architecture Diagram

Ascend Engines

Instead of separating execution into off-chain and on-chain domains, Ascend structures protocol logic into deterministic execution engines, each enforced through Midnight ZK verification.
Executes probability-priced event perpetual orders with deterministic matching.
Evaluates margin, leverage, and liquidation conditions in real-time.
Manages funding and trading account state transitions.
Handles internal and external fund movements securely.
Governs event lifecycle, resolution, and settlement.
All engine outputs are subject to ZK-verified constraints and committed via Midnight.

Execution & Verification

Trade Execution Flow

1

Sign

Orders are signed using native ecosystem credentials (Cardano, EVM, or Solana)
2

Match

Orders are interpreted by the Ascend Matching Engine
3

Validate

Execution results are validated by the Risk Engine
4

Commit

Final state transitions are proven and committed on Midnight

Risk & Liquidation Enforcement

  • Margin requirements evaluated per trading account
  • Liquidation conditions checked deterministically
  • Liquidation actions only applied if ZK-verified as fair

Account Architecture

Funding Account

The primary on-chain ownership entity within Ascend.
  • Accept and manage deposits
  • Process withdrawals
  • Transfer funds between accounts
  • Allocate capital to trading accounts
Tracks collateral, linked accounts, permissions, and multi-sig thresholds.

Trading Account

Subordinate accounts dedicated to trading operations.
  • Isolated margin per account
  • Independent liquidation conditions
  • Position and funding tracking
Multiple trading accounts can link to a single funding account.

Account State Model

All account-related state is maintained as zero-knowledge–verified state on Midnight.
Account TypeState Includes
Funding AccountCollateral balance, linked trading accounts, roles & permissions, multi-sig config
Trading AccountActive positions, margin utilization, funding adjustments, liquidation status

Identity & Credentials

Ascend implements a fully cryptographic identity framework working with existing KYC, KYB, and identity providers.

Multi-Account Control

A single user may control multiple protocol accounts

Key-Based Ownership

Account ownership tied to cryptographic keys

Signed Authorization

All actions enforced through signed transactions

No Web2 Layer

No separate Web2 identity required for execution
This model removes the need for a Web2/Web3 credential split while preserving institutional-grade permissioning and access guarantees.