Proposal: Dynamic Surcharge Pricing for Fees on withdrawals over a changing amount

Testudo et Lepus

barlowtortoisehare_400
Of the Hare, and the Tortoise.

Note: Testudo more formally refers to a roman military formation, and not to the creatures belonging to the testudine family. The phrasing is entirely intentional, as the testudo formation was in fact both a defensive and offensive posture, which this could be.

TL;DR:

Abstract

Utilize ‘Fees’ as a method of disincentivizing short positions and dumps by dynamically changing ‘fee’ rate,
where the fee rate is zero for those transfers below the trailing transfer average rate.
This means that transfer’s exceeding the combined average transfer rate would have a fee imposed.
The vast majority of users would not incur this fee or could simply wait between ‘epochs’/‘time periods’
to withdraw *feeless.

Potential Implementation

as a component either to high risk assets (to enable price protection against dumping)

as a module for vaults in general (this would require more extensive testing)

as an optional component with user opt-in

as a module for ‘yUSD’ (or some variation, e.g. yyUSD) so that additional stablecoins (i.e. yet to be proven) may be included

Introduction

[You can’t use ‘macro parameter character #’ in math mode so I just took screenshots of the LaTeX :frowning:]

We propose a crypto-derived functional asset in which controllable volumetric functions are embedded
within the operational utility of the asset. As a result this function exhibits desirable properties
as a unit of account for its underlying asset.

In essence by utilizing the acceleration and deceleration (i.e. velocity) that the speed of the ERC20
token transfers (e.g. average transaction rate/mean transaction rate) can help to counter-balance
and reduce the market price volatility of the faster base currency ($ETH). Our focus is on
purely-virtual crypto currencies, which are based on computational assets e.g. as BTC, which is
based on “mining”, or ETH, which is based on computational “GAS”.

By utilizing small volume movements and disincentivizing the larger ones without compensation to
holders every exceeding unusual trade of the token is tracked by the smart contract and higher
“interest” fees are applied (re: withdraw, or ‘consumption’).

Transference of funds below daily volume threshold does not impose any interest fee.

When the threshold has been exceeded some percentage of tokens gets burned, for the transfer, for
deposit or for withdraw of the base instrument (ETH).

Thresholds are tracked individually per address as the average rate and have a function by which
they operate on.

‘evo-’ tokens are minted and burned on-demand by deposit and withdraw operations directly via
the contract.

Think of ‘evo-’ as a prefix/marker: much like ‘aDai’ or ‘cDai’, and of course, ‘yDai’

Initiated Protocol Operations

  • Deposit
  • Withdraw
  • Transfer

These operations contribute to the transfer rates. Transfer rates are tracked both in
aggregate
and individually (i.e. per address). The period of time for tracking is the last
25 days

EVO Protocol is determined both in aggregate (dynamically) and individually for each address
based on transactional (i.e. volumetric transactional information) stored and updated through the
smart contract during the previous transactions.

All three operations such as deposit, withdraw and transfer can equally contribute to the transfer
rates that are tracked totally and individually(as per holder) by the smart contract for the period
of the last 25 days.The token price is determined dynamically(and individually for each holder)
based on the information stored or updated in the smart contract during previous transactions:

{equation.EVO Protocol}

P_{t+1}(h, a):=\sqrt{\frac{D_{t}}{S_{t}}}+I_{t+1}^{\prime}(h, a)

The above equation will compute the price for a holder $$h$$ to purchase a certain amount of EVO
tokens in exchange for a base deposit in ETH/WETH at the given discrete time - $$t +1$$ , where
$$Dt$$ stands for the deposit of ETH in the smart contract at previous time - point and $$St$$
stands for the total supply of EVO tokens so far.

The first component with the token - base ratio $$Dt/St$$ under the square root is the indicative
price
and does not depend on the purchase/transferred amount, $a$.

Ergo, the component $$I_{t+1}^{\prime}(h, a)$$ is called the discounted interest rate and it can
grow proportionally to a within a range of $$[0, 0.24]$$ of $$a$$.

Higher interest payouts can slow down, deaccelerate, the price movement. Interest rate
determines how fast, or accleration, such price can change depending on the market demand &
supply pressure for EVO-based tokens. Interest[#] is computed individually for each EVO holder.

Note that all interest payments are contributed to the same common deposit Dt on the smart
contract, which is supporting the indicative price. This means that interest is shared by all
holders that choose not to trade their tokens at the moment.

An ERC20 smart contract will contain the information about the balance of every address,

Address Information (i.e. wallets)

$$B(h) s.t. Bt + 1(h, a): = Bt(h) + a$$.

In addition to the individual balances, EVO Protocol contract keeps track about how much each holder
has transferred in the last epoch (i.e. 25days)

Total average transfer rate for an address

$$avg(Rt + 1(h, a)): = avg(Rt(h)) + a$$

Total average daily transfer rate for all holders

$$avg(R¯ t + 1(h, a)): = avg(R¯t(h)) + a$$.

Calculations

More formally calculation of the individual interest rate as well as the applied ownership discount
can be described in following steps:

Therefore it can be expected that the demand for EVO Protocol based tokens like EVO Protocol will be
able to represent the demand for the value storage, whereas EVO Protocol represents the value of
storage as a derivative function of the underlying asset, Ethereum (i.e. gwei, or as a fixed unit of
account for contracting)

5 Likes

I am still digesting this proposal, but as someone who is weary of most proposals to increase fees, this is precisely the type of proposal I could get behind.

1 Like

I will add some simulations, etc, and do a historical analysis to approximate the time periods that are optimal.

This is not increasing fees: this is placing fees into two categories:

which types of transactions should incur fees
and out of that subset of transactions, which should incur a fee

You pay a penalty for withdrawing out of a CD for example or a 401k.

better yet, think of this as Uber Surcharge pricing on fees but for withdrawals over a certain amount that dynamically adjusts (just like surcharge pricing)

I will fix the LaTeX now that the glorious admins have enabled it on the forums.

Sam

1 Like

I think this type of complex proposal flies in the face of simple, composable, financial building blocks that IMHO is a fundamental founding principle for DiFi

I think this is an interesting idea, but yeah, it would really be great if we could see backtested data of what something like this would look like on one of the vaults. I’m sure I’m not the only one whose math skills aren’t quite up to parsing out the equation :sweat_smile:.

Also, am I understanding correctly that if a yVault were seeing massive deposits, it might also see fees charged to those who are depositing? How is this beneficial? I’m sure you’ve thought of this, and I’m curious what the answer is.