Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Users submit transactions that place and fill orders directly to the chain. Elliptic's bridge shares user A's crossing orders with user B. User B uses this knowledge to complete their ZKPs.
Dark pools in traditional finance are used for minimizing price impact. The Unyfy team sees the role of dark pools in crypto in an entirely different light. Rather than using its properties to protect institutional traders in big cap markets, we aim to protect community members in small cap markets.
The Unyfy Dark Pool is the backend infrastructure that powers the protocol. As the token becomes high volume, DeFi scavengers such as MEV and snipers will be out there, and just providing the litpool in groupchat is not going to prevent this. An elegant solution therefore is making the primary medium of token exchange a darkpool, and filter out the small orders into GroupFi.
Observers should have no bearing on the distribution of liquidity across prices. There could be large orders right above or below the mid-price with enough liquidity to absorb adversarial pump and dumps. As such, bots who attempt to manipulate the market do so at a significant risk to their treasuries.
We've streamlined our construction to shield prices of open orders, and not a single bit more. Total buy and sell side liquidity, depth at the best bid / ask, exchange paths, and filled orders are all public by design.
This aligns with Elliptic's goals of building maximally transparent systems with the minimal shielding mechanics that people needed to build interesting applications. Our design philosophy yields the following benefits for Unyfy:
Fast client-side proving. We've removed all instances of merkle trees (600 constraints
per hash on top of an average tree depth of 32), non-native field aritmetic (4000 constraints
per mul), and group operations (2000 constraints
per point mul). Our circuits are simple, and that's reflected in our proving times. The UX benefit is significant.
Information equity. Efforts to shield on-chain state are commonly thwarted with statistical analyses. Many protocols are theoretically hiding, but fall short in practice. The small subset of the population able to compile heuristics and develop effective models reap all of the benefits of knowing what they shouldn't. Even worse, users of the protocol operate under the assumption of complete information asymmetry when it is seldom the case. Actively shielding as little information as possible mitigates these inequities in knowledge.
Compliance. Providing anonymity brings unwanted illicit activity and regulatory risk. We do not provide anonymity.
We instantiate our zero knowledge proof system $(P, V)$ over the curve bn128
. All variables are in its scalar field $F$.
An order is represented as the following object, with a transparent structure $t$ and shielded structure $s$:
with the following definitions:
$\phi$: side of the order, 0 when it's a bid, 1 when it's an ask
$\chi$: token address for the target project
$d$: denomination, either the token address of USDC or ETH (set to 0x1
for this case)
$p$: price, denominated in $d$, with scaling factor $10^9$ but only $10^7$ precision
$v$: volume, amount of token to exchange, with scaling factor $10^9$
$\alpha$: access key, randomly sampled from $F$, protects against brute force attacks, meant to be revealed to counterparties
We employ a cryptographic hash function $H$ to create hiding commitments for the shielded structure. The chain only sees the commitment $\bar O = {t: O.t, s: H(O.s)}$.
The on-chain orderbook comprises of 1) a list of these comitments ${\bar O_i}_{i=0}^N$ and 2) the Ethereum public keys $pk$ of the commitment owners.
When describing the protocol, we often employ an auxiliary variable $b$ to describe a balance. It is a pair with the first element specifying an amount of the target project's token and the second element specifying an amount of the denomination token. A balance will always be used in conjunction with an order $O$, so target and denomination tokens are unambiguous.
Readers will have to excuse our blend of lax notation from mathematics and lax notation from computer science. The purist descriptions grew too verbose. Scaling factors are also redacted for brevity, but must be included during implementation to handle float operations.
The chain is the source of truth for dark pool state and token ownership
Construct $O_{cho}$ with all attributes of $O_{own}$, subtracting $\gamma$ from volume and replacing the access key with a newly sampled $\alpha$. If $\gamma == O_{own}.s.v$, then use dummy values for $O_{cho}$.
Construct $O_{chn}$ with all attributes of $O_{n}$, subtracting $\gamma - \sum_{i=0}^{n-1} O_i.s.v$ from volume and replacing the access key with a newly sampled $\alpha$. If $\gamma == \sum_{i=0}^n O_i.s.v$, then use dummy values for $O_{chn}$.
Construct $\bar O_{cho} = (O_{cho}.t, H(O_{cho}.s))$ and $\bar O_{chn} = (O_{chn}.t, H(O_{chn}.s))$.
Add ${\bar O_{own}, {\bar O_i}{i=0}^n, b{own}, {b_i}{i=0}^n, O{n-1}.p, \bar O_{cho}, \bar O_{chn}}$ as public outputs.
Bid Case ($O_{\text{own}}.t.\phi=0$)
Ask Case ($O_{\text{own}}.t.\phi=1$)
Initial
Initial
$b_{\text{own}} = (0, (O_{\text{own}}.s.p) (O_{\text{own}}.s.v))$
$b_{\text{own}} = (\gamma, 0)$
$b_i = (\gamma_{i}, 0)$
$b_i = (0, (O_{\text{i}}.s.p)(O_{\text{i}}.s.v))$
Final
Final
$\gamma = \sum_{i=0}^{n-1} \gamma_i + k$
$\gamma = \sum_{i=0}^{n-1} O_{i}.s.v + k$
Orders 0 to $n-1$ fully filled,
Orders 0 to $n-1$ fully filled,
$n^{th}$ order at least partially filled.
$n^{th}$ order at least partially filled.
$k \leq \gamma_n$
$k \leq O_{n}.v$
$\nu=(O_{\text{own}}.s.p)(O_{\text{own}}.s.v)-\sum_{i=0}^{n-1} \gamma_i(O_i.s.p) - k (O_n.s.p)$
$\nu= \sum_{i=0}^{n-1} (O_i.s.v)(O_i.s.p) + k(O_n.s.p)$
$b_{\text{own}}=(\gamma, \nu)$
$b_{\text{own}}=(0,\nu)$
$b_i$ for $0\leq i < n= (0, (O_{\text{own}}.s.p) (O_{\text{own}}.s.v))$
$b_i$ for $0\leq i < n= (O_i.s.v,0)$
Here, $\gamma_i == O_i.s.v$
$b_n=(\gamma_n-k, k (O_n.s.p))$
$b_n=(k, (O_n.s.p)(O_n.s.v-k))$