Trading

this page describes leveraged trading mechanics inside marginly protocol.

Margin and Leverage

• Users who want to leverage long ETH deposit ETH margin.

• Users who want to sell ETH short deposit USDC margin.

Marginly works with margin, so the margin for longs is always the base asset (e.g., ETH), while the margin for shorts is always the quote asset (e.g., USDC).

Long buyers have ETH recorded as collateral, and USDC recorded as debt. Short sellers have USDC recorded as collateral, and ETH recorded as debt.

Let’s consider a simple example here:

• the market price is 1000 USDC for 1 ETH

• user1 deposits 1 ETH into the pool

• user2 (the short seller) deposits 100 USDC margin and sells short 1 ETH on Uniswap v3 depositing back the 1000 USDC trade proceeds (all atomically in one transaction thanks to Marginly smart contract design)

The pool configuration in this scenario is shown below: (the "+" sign means collateral, while the "-" sign means debt)

User	ETH+	ETH-	USDC+	USDC-	NetPos	Leverage
1	1	0	0	0	1000	1
2	0	1	1100	0	100	11

Current pool balances are:

ETH balance: 0 USDC balance: 1100

Now user 3 comes in and longs ETH: he puts in 0,2 ETH margin and longs 1 ETH borrowing 1000 USDC from the pool. The pool positions configuration now looks the following way:

User	ETH+	ETH-	USDC+	USDC-	NetPos	Leverage
1	1	0	0	0	1000	1
2	0	1	1100	0	100	11
3	1.2	0	0	1000	200	6

Current pool balances are:

ETH balance: 1.2 USDC balance: 100

As you may notice, pool balances change between ETH and USDC, reflecting users’ trades. You also may see that the pool can leverage against itself: in the example above, there is only 100 USDC left in the pool, while the total debt in the system is 1000 USDC: pool balances reflect the net positions, while users may be levered both long and short.

Marginly does not require traders to fund 100% of their position. There is a maximum leverage of 20x for traders, meaning that for every $1 of margin deposited, traders can can trade with up to $19 additional capital.

If a trader's position exceeds the maximum leverage, it will become eligible for liquidation (or deleveraging with no liquidations in future protocol versions).

Liquidations

When a user's position leverage exceeds maximum leverage, the position becomes eligible for liquidation. This section provides a brief overview of how liquidation process works in Marginly. Unlike, let’s say Compound v3, which only allows for position absorption, Marginly has a multiple-step process:

1. Marginly protocol liquidates user positions automatically on any user action as the system keeps on-chain lists of “bad” (in the order of descending leverage) positions both long and short. This proved quite effective on the testnet. Basically, if trades/user actions happen every block, the system checks for liquidations and performs them when needed every block. Currently the protocol liquidates only the top worst position both long and short. This is done for gas optimization reasons, as liquidating multiple positions could harm the user who invoked the liquidation. Effectively the liquidation penalty on every position in the system is 1 / max leverage = 1 / 20 = 5%, so the entire Marginly pool earns penalties on liquidations.

2. Additionally, Marginly offers a keeper service which can absorb underwater positions (underwater position is a position whose leverage is greater than the critical). Ultimately the keeper's account will be the position holder with all of its assets and liabilities. This position is subject to all the liquidation checks just like any other. If the keeper doesn’t have sufficient funds to absorb the losses, he won’t be able to do the liquidation. To mitigate this Marginly sets aside a fraction of swap fees as an insurance cushion to be used by the keeper. Marginly provides keeper service as an open source software and encourages users to run multiple instances of the keeper to compete for liquidations and liquidation penalties. However, Ideally we would want liquidations to happen automatically as in point number one above. If keepers earn penalties to themselves, the pool LPs will not earn this reward.

3. Finally, Marginly does have no-liquidation mechanics we call deleveraging. Marginly resorts to deleveraging when the protocol needs to liquidate the borrower but there is not enough collateral in the pool to sell.

For future versions (e.g. Marginly v2) we seek to expand the deleveraging idea and employ it as a default option: e.g. instead of liquidating a user on an external market have his position go to the opposing side reducing the overall pool leverage this way. Short sellers will absorb liquidating long positions and vice versa. To achieve this and design a beautiful self-adjusting system we need to perform R&D and do some careful modeling to account for various pool imbalance scenarios.