# Offshift anon Litepaper

*An On-Chain Synthetics Platform for Anonymous Yield Generation*

*NOTE: The Offshift anon Litepaper is a living document whose contents may be modified by Offshift Core in response to ongoing research.*

## Table of Contents

- **I.**  [Abstract](#i-abstract)

- **II.** [Value Proposition: Offshift anon](#ii-value-proposition-offshift-anon)

- **III.**  [Protocol Features and Dynamics](#iii-protocol-features-and-dynamics)

  - A. [Capital Dynamics](#a-capital-dynamics)

  - B. [Shifting Circuit](#b-shifting-circuit)

- **IV.**  [Platform Tokenomics: Utility and Incentives](#iv-platform-tokenomics-utility-and-incentives)

  - A. [Shifting with the Burn-and-Mint Mechanism](#a-shifting-with-the-burn-and-mint-mechanism)

  - B. [Market Making via LP Rewards](#b-market-making-via-lp-rewards)

  - C. [Price Parity via Flex Fee](#c-price-parity-via-flex-fee)

- **V.**	[Disclaimer](#v-disclaimer)

- **VI.** [References](#vi-references)






# I. Abstract

DeFi protocols provide users opportunities to generate yields on their assets in exchange for providing liquidity. DeFi platforms operate predominantly on the Ethereum public blockchain, and provide little to no considerations for user privacy. As such, there exists substantial, untapped demand in the Ethereum DeFi ecosystem for a platform that eliminates the financial trade-offs between privacy and DeFi.

Offshift anon is a fully on-chain, non-custodial platform designed to provide protections for user privacy without compromising yield potential. On Offshift anon, users burn XFT to mint on-chain synthetics called anonAssets via a tokenomic process called Shifting. Shifting dissociates users from their XFT, and thereby renders users anonymous with respect to their freshly minted anonAssets. As standard, public ERC20 tokens, anonAssets introduce no novel barriers to feature implementation or platform integration in the Ethereum ecosystem, and therefore eliminate yield-related tradeoffs associated with privacy.





# II. Value Proposition: Offshift anon

**Offshift anon dissolves the existing tradeoffs between privacy and yield generation by dissociating users from their assets via the Mint-and-Burn Tokenomics native to the Offshift Ecosystem.** On Offshift anon, users burn XFT in order to become anonymous owners of the anonAssets they mint. Users may subsequently begin exploring opportunities to engage DeFi applications with their anonAssets while remaining fully anonymous. Essentially, Offshift enables individuals to anonymize their crypto positions, so they can both invest in the technologies they support and generate yields without the drawbacks related to exposure and public profiling.





# III. Protocol Features and Dynamics



## A. Capital Dynamics

On Offshift anon, users may perform two different capital transfers.

| Offshift anon Capital Transfers |
| ------ |
| **1. From XFT to anonAssets** |
| **2. From anonAssets to XFT** |



Offshift also facilitates two different Shifting types.

#### 1. Anonymizing Shift (anonShift)

An Anonymizing Shift, (herein referred to as an anonShift) both (a) dissociates sender of funds from receiver of funds, and (b) may change the form in which the Shifted value is stored. An anonShift with input XFT will always output one of several anonAssets.

#### 2. Simple Shift

A Simple Shift is transparent and confers no anonymity; it simply shifts value from one asset type to another. A Simple Shift with input anonAsset will always output XFT. A Simple Shift with input XFT will always output anonAsset.



---


||**Anonymizing Shift**|**Simple Shift**|
| :-- | :-: | :-: |
|**XFT to anonAssets**|**✓**|
|**anonAssets to XFT**||**✓**|


---



## B. Shifting Circuit

In executing an anonShift, Offshift’s Shifting Circuit functions as follows.



#### 1. Fetch Price Feed

As a prerequisite to beginning an anonShift, a user must hold and approve an amount of the input asset (XFT) that is greater than or equal to the output amount specified in the deposit contract. Since the input and output are different assets, a price feed is fetched to ensure a depositor has a sufficient balance. If so, the user must then grant the spender (the deposit contract) an allowance of the input asset greater than or equal to the required input amount.



#### 2. Generate Secret

On the client-side, two 31-byte integers are generated pseudorandomly. One integer is the secret value that will be committed, and the other is a nullifier value that prevents attackers from using the committed secret value to generate fraudulent proofs, as well as double spends on deposits. Together, these concatenated integers (nullifier + secret) create what is called the "preimage" of the commitment.[^1]



#### 3. Commit Secret and Nullifier

Once the secret and nullifier values are generated and the commitment preimage is formed, it is converted from a 62-byte integer value into a Pedersen hash. In other words, the commitment preimage is mapped to a point (X, Y) on the Baby Jubjub elliptic curve.[^2] This point (X, Y) is subsequently encoded as a 32-byte big-endian integer.



#### 4. Insert Deposit into Merkle Tree

Now that the secret and nullifier have been Pedersen-hashed into a point on the Baby Jubjub elliptic curve and encoded into a 32-byte big-endian integer, the integer is MiMC[^3]-hashed and inserted into a Merkle tree[^4] of height 20 (a tree with 2^20 leaves) for efficient storage and lookup. For the purposes of our zero-knowledge proof, this storage structure provides an efficient method for proving the existence of a valid deposit without revealing its corresponding Pedersen hash.

In addition to inserting the MiMC hash into the deposit Merkle tree, a price feed is fetched for the output asset, and a corresponding amount of the input asset is burned by calling the burn function in the input asset contract. For example, 100 USD worth of XFT is burned for a 100 anonUSD anonymity set. 

Note: While the output amount of the deposit contract is fixed, the amount of XFT needed to enter the anonymity set is variable, and is determined by the price feed.

Note: As the deposit count increases for a given anonAsset denomination, it becomes increasingly difficult for an adversary to determine which deposit corresponds to a given withdrawal. In other words, the longer a specific deposit remains in the anonymity set, the less likely it is to be linked to a specific commitment redemption.



#### 5. Withdraw and Mint anonAsset

To redeem a committed deposit and mint the denominated anonAsset, a user must provide a valid zero-knowledge proof to the on-chain verifier contract, and verify that a given nullifier has not been previously spent. To do so, the withdrawing party must provide the following inputs:

- **Public Inputs:** A recent root of the Merkle deposit tree, and a Pedersen hash of the nullifier component computed before deposit.
- **Private Inputs:** The nullifier integer (generated in step 1), secret integer (generated in step 1), and node labels and path to the root provided in the public input.

The zero-knowledge[^5] proof generation is carried out as follows.[^6]

The "witness" for the SNARK is computed by running the preimage of the commitment (nullifier + secret) through a circuit component that computes the Pedersen hash of the preimage, as well as the Pedersen hash of the nullifier. The circuit then asserts the equality of the hashed nullifier against the one provided as a public input.

The circuit then asserts that the provided commitment hash is in fact under the provided Merkle root. To begin, the circuit takes as input the following values: the MiMC hash of the committed value, the MiMC hash of the value adjacent to the commitment, and a direction selector for the user's value (0 for left, 1 for right). The circuit computes the hash of the two inputs, and then iterates the process for each level of the tree with the provided path elements and direction selectors. If the computed Merkle root matches the one provided as public input, the process is completed and the deposit is validated.

To complete the withdrawal, the verifier contract asserts that the provided Merkle root is within the 100-root historical record and the result of the verifier, and that the provided nullifier hash has not previously been spent. If these three conditions are met, then the denominated anonAsset is minted to the provided recipient address, thus completing the deposit/withdrawal process.





# IV. Platform Tokenomics: Utility and Incentives

Offshift anon’s platform tokenomics incorporate various tools and incentives to ensure both robust price parity and adequate public market liquidity for anonAssets.



## A. Shifting with the Burn-and-Mint Mechanism

Like all PriFi Applications in the Offshift Ecosystem, Offshift anon employs Burn-and-Mint Tokenomics to facilitate seamless capital flows between XFT and anonAssets.

The **Burn-and-Mint Mechanism** burns a user’s XFT and mints an anonAsset of equal value. At any point, a user may also **Shift** from an anonAsset back into XFT, and the process reverses: the **Burn-and-Mint Mechanism** burns the anonAsset, and mints new XFT of equal value to the user’s designated ERC20 wallet address. Such a model enables users to mint, store, and exchange anonAssets free from collateral requirements and the margin calls and liquidations that come with them, making for a simplified and cost-efficient trading experience. It should be noted that although such a tokenomic model demands an elastic supply model for XFT, it does not imply or require any propensity toward long-term inflationary or deflationary monetary attributes.



## B. Market Making via LP Rewards

As fully composable, standard ERC20 tokens, anonAssets can be Shifted through Offshift’s Shifting Circuit, and may be integrated into various Ethereum DeFi applications as well. To support demand for anonAssets in public markets, Offshift Core will deploy XFT to incentivize anonAsset LPs and ensure adequate liquidity levels in anonAsset markets. Quantitative metrics will be announced at the proper juncture.



## C. Price Parity via Flex Fee

In order to support price parity, Offshift anon employs simple mechanics to stabilize anonAssets. 

In the event anonAssets exceed price parity due to incremental buy-side pressure, Offshift anon’s Simple Shifts allow arbitrageurs to restore price parity efficiently by Shifting from XFT to anonAssets at the lowest cost possible.

In the event a designated anonAsset falls to 2.5% below price parity due to incremental sell-side pressure, Offshift’s protocol triggers a variable Flex Fee on Shifts from the anonAsset to XFT. The Flex Fee varies in direct proportion to the anonAsset’s discount to par value, and remains in effect until the anonAsset returns to less than 2.5% below price parity.





# V. Disclaimer

XFT tokens should only be purchased after developing a full understanding of the nature and functionality of the tokens, the risk of potential loss, and the protocol on which XFT operates. Offshift intends to operate within the law and is not to be used as part of any regulatory or statutory violation. Consult a professional for legal or financial advice.





# VI. References

[^1]: https://en.wikipedia.org/wiki/Image_(mathematics)

[^2]: https://eips.ethereum.org/EIPS/eip-2494 

[^3]: https://byt3bit.github.io/primesym/

[^4]: https://patents.google.com/patent/US4309569

[^5]: http://www.zeroknowledgeblog.com/index.php/groth16

[^6]: https://eprint.iacr.org/2016/260.pdf