Nyx

2 main ideas, combined to shield traders from predatory public exploits while maximizing the earning power of their collateral.

A fully private perp DEX: Built natively in Daml on the Canton Network, the DEX ensures sub-transaction privacy. This is done by using a private orderbook with peer-to-peer settlement. Only the venue can see the orderbook (to match orders), meaning no liquidation hunting, no front-running, no copy trading. Traders' positions, margins, and exposure are completely hidden from non-participants. Comes with all the perks of a regular perp DEX (including leverage), but without the con of broadcasting your activity for bad actors to take advantage of.

Margin trading with yield-bearing RWA as collateral: You can hold RWA’s like Gold or MMF’s as collateral when you trade with leverage on Nyx, earning yield as the asset appreciates, allowing traders on Nyx to have far greater capital efficiency. Chainlink data streams are used for our oracle for both RWA price and underlying asset price, and the oracle's signature is verified inside the Daml transaction, meaning marks, funding, and liquidations are anchored to real, signed prices, not a relayer we ask you to trust. Chainlink Proof-of-Reserve is also used to check that the collateral is actually backed before it's accepted.

The very idea of building an entire perp DEX from scratch for a hackathon was a huge undertaking which led to many technical roadblocks and learnings.

We chose to build on top of Canton’s best-in-class technology for privacy, allowing a truly private perp dex. This meant implementing a DAML layer to our application with 5 core templates: Market, Order, MatchedPair, RWAToken, and OraclePrice plus PoRAttestation. Every position is stakeholder-scoped to the venue, traders, regulator, and a uninvolved observer. Settlement gives us atomic delivery-vs-payment on PnL and collateral return in a single transaction. This was deployed on-ledger in a Daml package called perp-dex-v2 deployed to the Seaport 5n DevNet validator.

Our matching engine is a standalone C++ service that reads the resting order book and submits MatchOrders back to the gateway. We used C++ for performant, low-latency code, which is paramount in building critical financial infrastructure like a matching engine.

For our Chainlink Integration, we use Data Streams over both REST and WebSocket. We parse V3 reports for ETH/USD, validated against a real live report. Proof of Reserve is wired as a PoRAttestation template that asserts reserves >= issuedSupply before any RWA collateral is accepted. The Chainlink-on-Canton Verify choice is plumbed behind a PriceOracle interface so the mock and the verified path are a one-template swap. We chose to integrate with Chainlink because they provide low-latency price streams for all the assets we need, and furthermore their PoR allows us to ensure trust end to end.

A fun technical challenge was, in ensuring our books would have liquidity at first, we had to write a market-making bot (represented as a party on Canton). This implementation was tricky, as we had to continually react to price movements in the underlying asset (ETH) and continually requote to ensure competitive prices.

The wallet we used generates an Ed25519 keypair in the browser, onboards an external party, signs the topology multiHash. The participant does not auto-sign anything for us. The M2M OIDC token does HTTP auth; the party's private key does transaction signing. Two different trust planes, kept separate on purpose.

Frontend is React + Vite with an in-browser Ed25519 wallet built on canton-network/wallet-sdk. The backend is a TypeScript gateway running on node that owns OIDC auth, the periodic jobs, and the bridge from off-chain price feeds into on-ledger state.