1 of 21

Unyfy

Overview

Intro to Unyfy

From Trader to Consumer

With Unyfy, project founders and users can unify multiple aspects of their ecosystem right within group chats. Unyfy incorporates four critical layers - notifications, finance (encompassing darkpools, orderbook, liquidity pools, auctions, trading, staking, lending, borrowing, and referral systems), and execution (integrated with smart contract blockchains).

Up until now, open defi protocols have predominantly functioned as an infrastructure for open, unrestricted financial markets, fostering a surge in financial and trading applications. This, however, has birthed several issues within the industry: rampant pump-and-dump schemes by traders, consolidation of power in the hands of centralized entities, substantial revenue leakages due to Miner Extractable Value (MEV), a disjointed user experience given the gap between traditional and web3 identities. These prevailing market dynamics significantly hinder the potential value tokens could bring to projects and their communities, stifling the realization of a more comprehensive and engaged ecosystem.

Unyfy addresses the pervasive issues in the blockchain space through a cohesive protocol that unifies project ecosystem in any community venue.

GroupFi

Concentrated Liquidity in Community Venues

While AMM is a great invention, its mechanism present many problems that prevent the full value of tokens to be realized by their communities:

In a TVL driven token market, new tokens face low liquidity meaning high slippage or price impact
Sniper bots and MEV bots extract economic benefits that could have been reinvested back into communities
User engagement is absorbed by Uniswap because start up projects have limited bandwidth develop their own token marketplace, thus challenging for projects to retain users

The goal of GroupFi is simple, to help projects convert financial network effects of token issuance into product network effects. Without reliance on TVL intensity, projects configure gated PVP order books that are embedded into their community venues. The benefit is that there is no requirement for providing huge liquidity upfront and worrying about sniper bots or MEV, because every trading activity happens within groupchat members.

The Unyfy protocol helps projects to achieve GroupFi by offering tools to build a community centric trading venue, where a token’s liquidity and defi ecosystem resides within community groupchats. Configured and operated by projects.

In terms of degree of openess to traders upon launch, GroupFi sits between the spectrum of IDO and hype launch. Imagine an invite only poker table, you trade against people in the groupchat, you know who you trade against and once they leave they cannot trade.

As the project becomes more mature, the community may prefer to supply LP on Uniswap for broader liquidity or the project may pursue listing on CEXes such as Binance, we do not prevent projects from doing this. In fact, social arbitrage between venues is healthy for the project's long term, the emphasis is that the most important portion of liquidity stays in project community venue so their users can always access the best price.

The Unyfy protocol helps projects to achieve groupfi by offering tools to build a community centric trading venue, where a token’s liquidity and defi ecosystem resides within community groupchats. Configured and operated by projects.

Unyfy Protocol

Trading Interface

Through Unyfy, project founders embed their token's financial ecosystem in their community venues such as official telegram groupchats.

For Users:

In-Telegram trade execution UI
Auctions, Staking, Lending and Borrowing, Governance in an unified experience
Compatibility with external exchanges to route txns; route txn through dark pools to ensure best price
Third party markets makers can be added

For Projects:

Gating: whitelist, KYC
Telegram bot integration for notifications and intent-based trading
Moderation of trading venue
Access controls

Community Venues

User trading interface stays in community venues such as Telegram

The user joins official TG groupchat
user DM the bot using /menu command
The bot will generate a multisig wallet for the user for deposit
The user deposits ETH into account
use /menu command to initiate trading within telegram, users can only trade tokens for groups they are in or given access to

Order Book Management

Dark Pool

Manipulation resistance for small cap tokens

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.

Defragmentation of Shielded State

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.

Price Shielding

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.

Representing the Limit Order Book

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$:

{
    t: (ϕ, χ, d)
    s: (p, v, α)
}

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.

Client Functions

// client functions
Users place orders by constructing $\bar O$, proving this was done faithfully, and backing it with the appropriate tokens. Bids are backed with the $d$ token. Asks are backed with the $\chi$ token. 

$place(\phi, \chi, d, p, v)$
1. Sample $\alpha\leftarrow$$ $F$. Construct $O = \{s: (\phi, \chi, d), t: (p, v, \alpha)\}$.
2. Run witness generation for the $back$ circuit, assigning its outputs $\{\bar O, b\}$ to local variables.
6. Let $P$ be the predicate "reveal this order iff it is finalized on-chain AND the requester owns an opposing active order within the limit bounds". Send $O$ and $\bar O$ to Elliptic. We will attach the predicate $P$. Elliptic acknowledges the message and sends back the signature $\sigma = Sign(sk_{ellp}, \bar O)$.
11. Generate ZKP $\pi_{back} = P(pp_{back}.pkey, \bar O, b)$, where $pp_{back}.pkey$ is the proving key for our $back$ circuit.
12. Publish contract call $place(\pi_{back}, \bar O, b, \sigma)$ to the chain, along with the tokens specified in $b$.

After commiting to an order $O_{own}$, the user can request Elliptic for all crosses up to 3x the order volume. For instance, a bid for 1000 `LINK` will return at most 3000 `LINK` worth of crossed asks. The user selects the best $n$ orders that cross $\{O_i\}_{i=0}^n$. Consuming all orders involved settles the trade. Settling will seldom be exact. For that reason, we create $\bar O_{cho}$ for the change order of $O_{own}$ and $\bar O_{chn}$ for the change order of $O_n$. These change orders are analogous to [Bitcoin change addresses](https://support.blockchain.com/hc/en-us/articles/4417082392724-What-are-change-addresses-and-how-do-they-work-#:~:text=Change%20addresses%20are%20an%20aspect,of%20the%20output%20being%20spent.).

$fill(O_{own}, \{O_i\}_{i=0}^n)$
1. Run witness generation for the $fill$ circuit, assigning its outputs $\{\bar O_{own}, \{\bar O_i\}_{i=0}^n, b_{own}, \{b_i\}_{i=0}^n, O_n.p, \bar O_{cho}, \bar O_{chn}, O_{cho}, O_{chn}\}$ to local variables. 
9. Let $P$ be the predicate "reveal this order iff it is finalized on-chain AND the requester owns an opposing order within the limit bounds". Send $\{O_{cho}, O_{chn}, \bar O_{cho}, \bar O_{chn}\}$to Elliptic. We will attach the predicate $P$. Elliptic acknowledges the messages and sends back the signatures $\sigma_{cho} = Sign(sk_{ellp}, \bar O_{cho})$ and $\sigma_{chn} = Sign(sk_{ellp}, \bar O_{chn})$.
11. Optional. Use Elliptic's circom library to encrypt $O_{chn}$ under a key $k$ that's shared with the owner of $O_n$. Add $Enc(k, O_{chn})$ to the ZKP. Unnecessary to do in the first release.
12. Generate ZKP $\pi_{fill} = P(pp_{fill}.pkey, \bar O_{own}, \{\bar O_i\}_{i=0}^n, b_{own}, \{b_i\}_{i=0}^n, O_n.p, \bar O_{cho}, \bar O_{chn})$, where $pp_{fill}.pkey$ is the proving key for our $fill$ circuit. 
13. Publish contract call $fill(\pi_{fill}, \bar O_{own}, \{\bar O_i\}_{i=0}^n, b_{own}, \{b_i\}_{i=0}^n, O_n.p, \bar O_{cho}, \bar O_{chn}, \sigma_{cho}, \sigma_{chn})$ to the chain. 

Users can cancel their open orders and regain the tokens that back them. This is straightforward in our open ownership model. The user only needs to prove the backing amount and sign the transaction using the ETH account of the owner. Logic for cancelling an order has heavy symmetries to placing one, with the below client function even using the same $back$ circuit. 

$cancel(O)$
1. Run witness generation for the $cancel$ circuit, assigning its outputs $\{\bar O, b\}$ to local variables.
2. Generate ZKP $\pi_{back} = P(pp_{back}.pkey, \bar O, b)$, where $pp_{back}.pkey$ is the proving key for our $back$ circuit.
8. Publish contract call $cancel(\pi_{back}, \bar O, b)$, receiving the tokens specified in $b$.

ZKPs for Attesting to Valid State Transitions

// We want to convince the verifier that the order committed to by $\bar O$ requires $b$ tokens to be unilaterally filled by a counterparty. For instance, an ask for 200 `LINK` must be backed by 200 `LINK`.

$back() \rightarrow \{\bar O, b\}$
1. Load private signals $\{O\}$.
2. Construct $\bar O = (O.t, H(O.s))$.
4. Compute the balance needed to back this order. If $O.t.\phi == 0$, then set $b = (0, (O.s.p)(O.s.v))$. If $O.t.\phi == 1$, then set $b = (O.s.v, 0)$. Notice that price is a free variable in both tuples. Observers will know the max amount of buy or sell side liquidity provided by this order, but have no information on the price this liquidity is introduced at.
5. Add $\{\bar O, b\}$ as public outputs.

Order commitments can only be consumed when balances are created according to the underlying orders. For instance, filling an ask for 20 `LINK` at the price of 1.32 `USDC` should result in a balance of at least 26.4 `USDC` for the order's owner. We also explicitly expose the price of the last order that was completely filled so observers can estimate the spread. 

Strong post-fill shielding is left out by design. The balance payout, along with the initial backing amount, allows observers to compute the price each $O_i \forall i \in [0, n-1)$ is filled at. We've confirmed with the Unyfy team that this does not take away from the effectiveness of their application. Exact prices for $O_{own}$ and $O_n$ are still shielded, though they are anchored to the exposed price of $O_{n-1}$. Balance computation is still done in-circuit, not primarily for shielding properties, but for succinctness since we are deploying to Mainnet.

$fill() \rightarrow \{\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}, O_{cho}, O_{chn}\}$
1. Load private signals $\{O_{own}, \{O_i\}_{i=0}^n\}$.
2. Assert $O_{own}$ is large enough to completely fill $\{O_i\}_{i=0}^{n-1}$ and at least partially fill $O_{n}$.
3. Construct $\bar O_{own} = (O_{own}.t, H(O_{own}.s))$ and $\bar O_i = (O_i.t, H(O_i.s)) \forall i \in [0, n)$.
4. Let $\gamma = min(O_{own}.s.v, \sum_{i=0}^n O_i.s.v)$ be the amount of $\chi$ token exchanged in this fill. 
5. Compute balances $b_{own}$ and $\{b_i\}_{i=0}^n$. If $O_{own}.t.\phi == 0$, then $b_{own} = (\gamma, \nu)$ and $b_i = (0, (O_i.s.p)(O_i.s.v))$. Compute $\nu$ by subtracting the cost of $\gamma$ tokens across $\{O_i\}_{i=0}^n$ from what the cost would have been at price $O_{own}.s.p$. If $O_{own}.t.\phi == 1$, then $b_{own} = (0, \nu$ and $b_i = (O_i.s.v, 0) \forall i \in [0, n-1)$ and $b_n = (\gamma - \sum_{i=0}^{n-1} O_i.s.v, 0)$. Compute $\nu$ by summing the cost of $\gamma$ tokens across $\{O_i\}_{i=0}^n$.

This might be a bit confusing for readers, so we clearly delineate how balances are updated in both bid and ask cases:

Bid v/s Ask Balance Updates

Bid Case ($O_{\text{own}}.t.\phi=0$)

Ask Case ($O_{\text{own}}.t.\phi=1$)

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

$\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,

$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))$

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.

Chain

The chain is the source of truth for dark pool state and token ownership

// The chain is the source of truth for dark pool state and token ownership
Contract behavior is fully specified by the above descriptions. Writing the psuedocode here for completeness. The Solidity complements of the core three functions all involve 1) verifying the ZKP for proper commitent construction and balance attestation, 2) distributing balances, and 3) tracking the consumption of commitments. 

The bulk of gas expenditure is from the ZKP verifier (300k gas) and the ERC20 `transfer()` (50k gas per balance) calls. As a rough estimate on Mainnet, this is $22 to fill one order against 6 orders and $14 to place / cancel orders. The actual costs when we deploy will be a bit higher when the other operations are included. 

$place(\pi_{back}, \phi, \bar O, b, \sigma)$
1. Assert $V(pp_{back}.vkey, \pi_{back}, \bar O, b)$, where $pp_{back}.vkey$ is the verifying key for our $back$ circuit. 
2. Assert $V_{sig}(pk_{ellp}, \bar O, \sigma)$, where $V_{sig}(⋅)$ is the algorithm from our chosen signature scheme.
3. Call `transfer(msg.sender, this, b.0)` for $O.t.χ$ and `transfer(msg.sender, this, b.1)` for $O.t.d$. Assume appropriate `ERC20` permissions.
4. Add $\bar O$ with owner `msg.sender` to contract storage.

$fill(\pi_{fill}, \bar O_{own}, \{\bar O_i\}_{i=0}^n, b_{own}, \{b_i\}_{i=0}^n, O_n.p, \bar O_{cho}, \bar O_{chn}, \sigma_{cho}, \sigma_{chn})$
1. Assert $V(pp_{fill}.vkey, \pi_{fill}, \bar O_{own}, \{\bar O_i\}_{i=0}^n, b_{own}, \{b_i\}_{i=0}^n, O_n.p, \bar O_{cho}, \bar O_{chn})$, where $pp_{fill}.vkey$ is the verifying key for our $fill$ circuit. 
2. Assert $V_{sig}(pk_{ellp}, \bar O_{cho}, \sigma_{cho})$ and $V_{sig}(pk_{ellp}, \bar O_{chn}, \sigma_{chn})$, where $V_{sig}(⋅)$ is the algorithm from our chosen signature scheme.
3. Assert $\bar O_i \forall i \in [0, n)$ and $\bar O_{own}$ are active orders, then remove all of them from contract storage.
4. Assert `msg.sender` is the owner of $\bar O_{own}$.
5. Call `transfer(this, O_i_owner, b_i.0)` for $\bar O_i.t.χ$ and `transfer(this, b_i.1)` for $\bar O_i.t.d$ $\forall i \in [0, n)$. Assume appropriate `ERC20` permissions.
6. Call `transfer(this, msg.sender, b_own.0)` for $\bar O_{own}.t.χ$ and `transfer(this, b_own.1)` for $\bar O_{own}.t.d$. Assume appropriate `ERC20` permissions.
7. Add $\bar O_{cho}$ with owner `msg.sender` to contract storage.
8. Add $\bar O_{chn}$ with the owner of $O_n$ to contract storage. 

$cancel(\pi_{back}, \bar O, b)$
1. Assert $V(pp_{back}.vkey, \pi_{back}, \bar O, b)$, where $pp_{back}.vkey$ is the verifying key for our $back$ circuit. 
2. Assert `msg.sender` is the owner of $\bar O$
3. Call `transfer(this, msg.sender, b.0)` for $\bar O.t.χ$ and `transfer(this, msg.sender, b.1)` for $\bar O.t.d$. Assume appropriate `ERC20` permissions.
4. Remove $\bar O$ from contract storage.

Use Cases

Community as Darkpool

Dark Pools

Dark pools are private asset exchanges designed to provide additional liquidity and anonymity for trading large blocks of securities away from the public eye. They provide pricing and cost advantages to buy-side institutions such as mutual funds, and pension funds, which claim that these benefits ultimately accrue to the retail investors who invest in these funds. However, dark pools’ lack of transparency makes them susceptible to conflicts of interest by their owners and predatory trading practices by HFT firms.

We introduce community as darkpool, a financial innovation where within group chats, members can utilize Unyfy's advanced financial tooling alongside zk-technology to facilitate partial orderbook reveal and privacy trades.

Community as Darkpool

Dark Pool Trading: Community members can engage in trading activities within a private, partially visible market, safeguarded from bad actors

Front-Running Prevention: The system inherently guards against front-running as the orderbook is not fully revealed.

Technology Integration: Utilizes the prowess of zk-technology to maintain the security and privacy of transactions.

PVP

Project owners can configure token gate settings for entrace requirements for being part of the group. These settings can be invite based as well. Traders counter trade each other with telegram or social handle visible.

Prediction Markets

Aside from GroupFi, prediction markets can be containerized and embedded within various groupchats.

Support

FAQ

What is Unyfy, and how can it benefit my startup?

Unyfy is a protocol for building seamless financial ecosystems within chats. Via Unyfy, startups can embed an AMM or order book directly into their community chats; liquidity is community-owned and safeguarded from revenue loss.

How Unyfy integrate with our existing chat platforms?

Projects can create, customize and configure telegram and discord bot on Unyfy platform. Projects can customize how their users interact and get notified with the project.

What financial customizations does Unyfy enable in my community chat?

At the beginning, Unyfy supports orderbook and AMM. Projects can set floor and ceiling for market making. Community can also provide liquidity to orderbook as well. The book will be transparent for both projects and users.

How does Unyfy ensure the privacy and security of our community's financial transactions?

Unyfy guarantees the privacy and security of your community's financial transactions through a fortified dual-node system. The challenging node rigorously verifies and confirms each transaction, ensuring the accuracy and safety of users' funds. In tandem, the monitoring node oversees the challenging node's activity, conducting a secondary verification of transaction data and ensuring the challenging node operates correctly.

Can Unyfy or Elliptic steal user funds?

No, users hold custody over their funds and have sole control over their orders.

Can users orders be consumed at a price outside of their stated bounds?

No, the integrity of filling orders is upheld via ZKPs.

Can the dark pool be used to launder money?

No, we’ve removed all components of anonymity from our protocol. All edges of the transaction graph are public. We do not run relayers. All observers will know who traded with who, along with the value transferred in each exchange. Furthermore, we do not allow users to deposit from one account and withdraw to another. We also take the additional precaution of deposit screening with long (6hr+) time delays.

Can a bot feign an order to see the whole order book?

No, they need to commit to the order to learn anything & Elliptic will only return the best crosses up to the order volume. If the attacker posts a small order with a wide range, only the single best price will be revealed. If the attacker posts a large order with a wide range, anyone can fill it. We can protect against commit-cancel patterns for this second case by enforcing a block delay- eg traders can only cancel orders after 10 blocks have passed.

Can attackers halt the protocol?

Yes, temporarily. Since Elliptic’s service for proof completion has hardware dependencies, attackers can mount physical attacks to take it down temporarily. The data availability solutions in place, however, let us reboot the service quickly. This dependency only applies to the matching process. At no point will any attackers be able to pause placing and cancelling orders. Funds can never be locked.

Can these hardware dependencies be exploited to harm users?

Yes. In the event of a catastrophic exploit, malicious parties could gain visibility into the orderbook. We have taken steps to mitigate this serious risk, including careful selection of secure enclaves, minimized hardware roles in the cryptosystem, and streamlined processes for switching providers. Note: this all only applies to the order book’s shielding property. At no point will attackers be able to steal funds or falsify order routing.