SQD Tokenomics 2.0.md

SQD Tokenomics 2.0.md

Tokenomics 2.0

The SQD Tokenomics 2.0 is designed for the phase that follows the initial "bootstrapping phase" when we subsidize the workers (the supply side) and make the usage essentially free (the demand side). Tokenomics 2.0 is based on the following principles:

• Allow the consumers (Portal runners) to pay in stables, reducing the exposure to $SQD volatility and velocity
• Make $SQD directly capture the protocol revenues and the network adoption (in particular, Portal registrations)
• Gradually reduce the amount of $SQD released for rewards so that:
  • The workers are not overly underpaid if the $SQD price is low
  • The workers are not overly overpaid if the $SQD price is high
  • Early adopters have an assymmetric risk/reward by not selling $SQD (similar to early Bitcoin miners)
• Make $SQD deflationary long term by accumulating USDT (liquid) revenues and buying $SQD on the market
• Generate the revenues on-chain and grow the Treasury
• Allow $SQD holders to earn yield in USDT (or other assets)
• Reduce the $SQD dilution, and incentivize long-term holding

The reward token

In order to achive the goals above, we introduce a new token, $rSQD used solely for paying out the rewards. $rSQD is going to be soft-pegged to USD via a stableswap mechanism, and the workers will receive both $SQD and $rSQD. The amount of $SQD distruted will be reduced, as the amount of $rSQD will be increased. The APY is controlled by yearlyRewardCapCoefficient, which will be gradually lowered to 25%, 15%, 10%, 5%, 3%, 1% respectively every 6 months.

In order the above mechanics to work the key pre-requisite is to make a stable and healthy market for USDT/$rSQD. The issuance of $rSQD should be at least 80% backed by the USDT liquidity to ensure that there's enough liquidity, and at the same time we should attract external liquidity providers to the market -- for that we can distribute $SQD as liquidity incentives for LPs.

$rSQD will be mintable, each new round of reward distribution will automatically mint the required amount of tokens. Note that it is completely independent from the depth of the available USDT/rSQD liquidity, and if it dries up $rSQD will (temprarily) de-peg. This should absorb short-term shocks but the goal is to build a market strong enough to sustain the peg long term. We also seed the initial liquidity and provide healthy and sustainable incentives for liquidity providers.

It's worth mentioning that proving $SQD liquidity incentives to LPs is going to be orders of magnitude cheaper compared to paying $SQD to the workers, as the LP incentive is normally a fraction of the volumes. That means that we can allocated say only 10% of the USDT/rSQD pool as $SQD incentives, wich means 10x less issuance compared to the direct rewards.

Staking rUSD for SQD

The demand for rUSD is additionaly boosted by the possibility to lock it into a staking contract and earn $SQD. This is additionally should drive back the peg should rUSD price go low, as one can buy it cheap, stake and get $SQD. The $SQD staking rate can be thought of a central bank base rate, set by the protocol.

SQD Borrow Pool USDT revenue streams

The current naked "Stake SQD to get Network access" model has multiple drawbacks:

• It does not generate the revenue streams (in particular, no USDT)
• The portal registration requires a substantial initial investment (10000 SQD min) and a token purchase
• The portal registration is bound to Arbitrum (high friction for non-EVM users)
• The network adoption is not directly connected to $SQD appreciation

The drawbacks above can be addressed by the device we call "SQD Borrow Pool". It meets the following goals:

• For SQD holders, it gives an opportunity to earn yield in USDT (and other liquid assets supported by the pool)
• For current and potential Portal users it allows to register and use the portal without purchasing SQD and in a capital efficient way, similar to paying a subscription in stables
• Generates a stable income in liquid assets (USDT) for the SQD Treasury, in particular for sustaining the rUSD peg
• Enables integtations with centralized payment providers or payments in foreign chains (in a centralized or potentially decentralized manner through cross-chain bridging an messaging).

For the sake of simplicity we assume that the "liquid asset" henceforth is USDT, but it can be any other (like USDC or ETH)

The Borrow Pool is a smart contract that supports the following functions:

• Provide (deposit) SQD (for USDT yield)
• Pay in USDT to register and use a Portal. One provides the desired request per second (rps), the subscription period and the payment in USDT.
• Terminate the subscription and withdraw the remaining USDT. The termination transaction can be made as a public method with a small fee attached to it, so that anyone can call it to receive the fee (it's a standard trick to "automate" transactions on chain)
• Withdraw the accrued USDT yield (distributed pro-rata to SQD depositors), paid from the fees collected from the USDT payments

For example this is how a centralized service (eg SQD Cloud) for registering Portals may look like:

• Accept credit card payments from the users
• Keep USDT on Arbitrum
• Whenever a user requests a Portal registration, collect the subscription fee, and initiate the registration on-chain
• Terminate and withdraw whenever the user subscription ends

SQD Treasury will be the first provider for the pool, and initiall we will make a cap on how much SQD can be provided.

The demand for rUSD (rSQD?) is additionaly boosted by the possibility to lock it into a staking contract and earn $SQD

Isn't it the same as UST-Luna scheme?

The issuance of $rSQD should be at least 80% backed by the USDT

They say that a 5% shortage on the supply side rises the price 5x. How much would 20% shortage affect the price? I assume, most worker operators don't care about the tokens and want to convert them to USDT asap. But the lack of USDT collateral will mean that only "the fastest" operators will get paid, and the others will be left with some tokens waiting that some LP will come and donate their money to get $SQD rewards. But I think it just delegates the part of the stress on the $rSQD/USDT to $SQD/USDT.

On the scheme it says

buy rUSD and burn it if rUSD/USDT > 0.8

Do you mean "rSQD/USDT < 0.8"? Who is the actor performing that and where do they get USDT?

Why isn't it enough to run the SQD borrow pool without the first part with a new token?
With the current approach there is a "value" of the SQD token — it's something you need to have to be able to run queries over the network. With the proposed approach I don't see the value of either SQD nor rSQD

Why isn't it enough to run the SQD borrow pool without the first part with a new token?
With the current approach there is a "value" of the SQD token — it's something you need to have to be able to run queries over the
network. With the proposed approach I don't see the value of either SQD nor rSQD

These parts are indeed completely independent

Isn't it the same as UST-Luna scheme?

I am not sure what UST-Luna scheme is. Anyways, we don't say that rUSD/USD peg is guaranteed and don't give and USD/rUSD yield on rUSD deposits that we can't finance

Do you mean "rSQD/USDT < 0.8"? Who is the actor performing that and where do they get USDT?

Yes right. The actor is the treasury, getting USDT from the fees (providing SQD to the borrowing pool and getting a % from the pool)

They say that a 5% shortage on the supply side rises the price 5x. How much would 20% shortage affect the price? I assume, most worker operators don't care about the tokens and want to convert them to USDT asap. But the lack of USDT collateral will mean that only "the fastest" operators will get paid, and the others will be left with some tokens waiting that some LP will come and donate their money to get $SQD rewards. But I think it just delegates the part of the stress on the $rSQD/USDT to $SQD/USDT.

We expect that non-trivial amount of people will be interested in stacking SQD, thus there will be some demand for rUSD that will go into staking (either directly or bought in the curve). Even if everyone rushes into selling rUSD and there's no buy demand, rolling out the program will only need about 10-20k USDT/month to sustain the peg (assuming 2000 workers and say 10$/node/month), which is definitely smth we can afford. Regarding the "stress" -- it's the opposite, operators selling SQD on the open market after collecting it for say 1 month give a lot more stress to the main token, while rSQD price/supply is much easier to maintain.

Luna was an attempt to create a stablecoin (UST) by tying to it to an unstable token (Luna) and buy/sell it automatically to regulate the price of UST. It crashed spectacularly, as predicted by the creator of Dai.

I understand that we don't really need it to be stable, but with such asymmetric reasons for demand and supply, the price is almost guaranteed to never be equal to 1$. Hence the question is what is the real value of this token?
If we are ready to "feed" the market with USDT to always bring it back to 0.8, then why not just use USDT for rewards directly? If not, then how will the operators be able to predict the amount of rewards they get?

operators selling SQD on the open market after collecting it for say 1 month give a lot more stress to the main token

Sure, but the same applies for the demand — if the clients start to pay for using the network, they will support the lower bound of the price

Sure, but the same applies for the demand — if the clients start to pay for using the network, they will support the lower bound of the price

They don't pay in SQD for using the network. Buying on the market and locking SQD on the open market is a lot of friction, and it's also a one-off buy, not a subscription.

Luna was an attempt to create a stablecoin (UST) by tying to it to an unstable token (Luna) and buy/sell it automatically to regulate the price of UST. It crashed spectacularly, as predicted by the creator of Dai.

The reason it crashed was an uncontrolled expansion of the supply and a bank run that ensued. None of that can happen in the current model. The reason to use rUSD is to have lower volatility and cheaper option then SQD. Using USDT directly is worse for two reasons:

• locking to a specific stable coin
• it's more expensive capital-wise, as with rUSD we expect to have an organic demand for it.

The price is almost guaranteed to never be equal to 1$.

It's the opposite. We can essentially guarantee the price to be $1 by allocating the backing funds for USDT 1:1. The point is that it's not necessary and partial backing suffices (and thus it's cheaper for us)

They don't pay in SQD for using the network. Buying on the market and locking SQD on the open market is a lot of friction, and it's also a one-off buy, not a subscription.

Both these problems are solved by the SQD borrow pool.

we expect to have an organic demand for rUSD

But why would anyone want to buy a token with no physical value which can only be used to earn another token with no physical value?

Let's imagine the case of SQD price dropping rapidly. In this case it becomes less appealing to buy rSQD for staking and the price on the dexes is pushed into the decreasing direction (everyone sells rSQD for USDT). We will have two options at this point: let the price de-peg or continue supporting it with 1-1 centralized swaps.
If we let the price de-peg, it causes even more panicking from the operators who don't believe it will rise back again, and they rush getting out the remainings of their rewards, making it even worse. The LPs will also have no motivation to lose their USDT just to get SQD rewards. As the result of such UX the price of SQD token can get even lower leading to the cycle of doom.

If we continue supporting the price with USDT we have to be ready to do it until the last penny, or it will de-peg later anyway.

To summarize my point

• I understand the desire to pay less real money for the rewards but the money can't be made from thin air, so this scheme seems to me like an attempt to hide the risks.
• Destruction of the physical value of the token will also destroy the reason for it to grow, so instead of being correlated to the technical value behind the product the SQD token will become mostly speculative.
• The ease of payments for the service is fully solved by the borrow pool.

Ok let me put it that way:
Option 1: Just lower the SQD rewards gradually (like in BTC), gradually reducing it to 0 (not that we have fixed supply of SQD and HAVE to reduce SQD emissions)
Option 2: Lower SQD rewards gradually + reward with rSQD (let's call it that way to not confuse about the depeg), with rSQD soft-pegged to the actual revenue generated by the network

In Option 2, SQD becomes deflationary, and the mental model for it is the "right to work token". That is, 100k SQD is a requirement to join the network and earn (and same applies to the borrow pool)

If we let the price de-peg, it causes even more panicking from the operators who don't believe it will rise back again, and they rush getting out the remainings of their rewards, making it even worse. The LPs will also have no motivation to lose their USDT just to get SQD rewards. As the result of such UX the price of SQD token can get even lower leading to the cycle of doom.

What you describe here is much easier to control externally vs SQD dropping in value (as buying up rUSD requires way less capital).
For comparison, to move SQD 1% up you need $100k-200k, and that amount is enough for at least 6 month of fully buying out rUSD emissions.

Destruction of the physical value of the token will also destroy the reason for it to grow, so instead of being correlated to the technical value behind the product the SQD token will become mostly speculative.

I don't understand this point at all. The opposite, the actual value of SQD is now clearly related to the network usage, as you can basically calculate the expected "right to work" price, and it becomes deflationary. Something similar to having a limit number of taxi licences for a growing city, leading to a gradual price increase per license.

Using USDT directly is worse for two reasons:

• locking to a specific stable coin

The stable can be changeable.

To migrate from USDT to USDC you issue a single transaction, that swaps all accumulated USDT and changes the reward contract to use USDC instead. The reward contract then distributes rewards from USDC pool according to the same ratios and mechanics.

We don't expect our reward pool to be large enough for the above swap to be problematic, right?

• it's more expensive capital-wise, as with rUSD we expect to have an organic demand for it.

Could you elaborate on this statement?

I see no capital expenses or need for any capital to drive the fixed stable token scheme. You accumulate the fixed token and distribute the exact same token. What can be more clear and fair than that?

Could you elaborate on this statement?
I see no capital expenses or need for any capital to drive the fixed stable token scheme. You accumulate the fixed token and distribute the exact same token. What can be more clear and fair than that?

The workers should get a stable reward income irrespective to how much revenue is generated. The r- token explicitly decouples that, and the bonding curve allows covering say 100k rUSD in rewards to be backed by just 20k in revenues

The stable can be changeable.
To migrate from USDT to USDC you issue a single transaction, that swaps all accumulated USDT and changes the reward contract to use USDC instead. The reward contract then distributes rewards from USDC pool according to the same ratios and mechanics.

These things get more complicated due to slippage and finding the right DEXes for liquidity when you start accumulating. But most importantly, the revenue streams are unpredictable and may not cover the operation expenses of the workers

These things get more complicated due to slippage and finding the right DEXes for liquidity when you start accumulating

Reward pool (as I understand it) collects income for some short period of time and then distributes it among workers and treasury.
It is inherently small. You have to be a unicorn to worry about slippage. Also migration from one currency to another is not required to use DEX at all. You just deposit new token, update reward pool setting and withdraw the old funds. That's it.

So, usage of a well known stable for rewards does not force us to stick with it in any way.

Now to more interesting part.

The workers should get a stable reward income irrespective to how much revenue is generated

First, this is far from obvious for me. Both from theoretical prospective (there are world states at which subsidising is useful), as well as from factual view (reaching that state is highly probable).

But, let's assume we want to subsidise.

The most natural way to do that is to simply generate the incoming traffic ourselves and to pay for it. That way it will be impossible for workers to gamble and they will be still encouraged to provide a high quality service.

I guess, the "essence" of rUSD is to create a credit line for that. What you suggest is to run a bank, but there are many other ways to get credit and there are many other ways to run a bank. All of that does not need to be coupled with reward distribution.

My summery on rUSD is as follows:

• It has high upfront cost (initial funding, consultancy fees, etc)
• It invites legal consequences of unpredictable scale
• It complicates reward acquisition for workers.

All the above goes even before any evidence, that such measures will be useful.

OK, let me try to distill the argument down to the first principles:

• The workers have to get at least say 100$ monthly per worker to operate sustainably (either in SQD, USD or an equivalent)
• The SQD has limited supply, and we don't want to introduce inflation, so we must drop the SQD emission part

That means that we have to reduce the SQD reward part rather quickly (down to to say 3% APR after 2 years from now). Thus, we need to additionally compensate the workers. There are different types of workers:

• Some who are not sensitive to the immediate operational costs but what to take as much upside as possible in SQD
• Some who operate for pure profit and immediately transfers the rewards for USD and immediate gains

Now let's compare rUSD vs USDT rewards, assuming that we want 20$/mo per worker and we have 2000 workers. So we need 40000$ + diminishing SQD rewards. Assume 10000$ is the monthy revenues from the borrowing pool.

USDT rewards case: We need to spend the remaining 30000$ directly (by borrowing SQD from ourselves?)
rUSD case: We issue 40000 rUSD from by the Treasury and have 10000 USDT from the revenue. Now, the workers receive 20$ rUSD each. Those for immediate profits, convert it to USDT. Those who want to maximize SQD holdings stake it to get more SQD.
Then there are two possible scenarios:

• The rUSD selling pressure is big enough so that the liquidity pool goes below 20% of USDT and the rUSD price starts to depeg exponentially. Then we can restore the peg and by out up to the whole 40000 rUSD with just 10000 USDT. The impatient workers who rush to sell get less
• The liquidity pool can sustain the (moderate) selling pressure and rUSD keeps the peg.

As you can see, the rUSD becomes a lot more capital efficient and allows the protocol accumulate the reserve fund.

It has high upfront cost (initial funding, consultancy fees, etc)

It is within the 200k USDT, that is 1-2 month of subsidies

It invites legal consequences of unpredictable scale

We already get a legal approval of this scheme

It complicates reward acquisition for workers.

The complication is mild, as the workers will have to off-ramp to fiat anyway. Right now they sell SQD, there's no difference to selling rUSD.

All of this sounds reasonable and convincing, but money can't be made of thin air, therefore there should be hidden risks, so I want to make it clear (at least for us) which side takes them.

I think at this point we agree that we'll have (at least for some period of time) to run an activity with revenues covering less than a half of spendings. The scheme you propose is taking the risks away from us — even in the worst-case scenario, we'll only have to cover a 1/4th of spendings with our real money. Apparently, all the risks go to the node runners — they pay a stable amount of real money for the compute resources, but there is a chance that the rewards won't cover the costs.

On the other hand, that's already how it works — they're paying real money to get SQD rewards which don't guarantee to cover the costs.

I can see the following implications of such a business-scheme (compared to fully covering the risks ourselves):

• it should be clearly stated that running a worker is effectively more like mining than renting compute resources
• the resource (number of workers) planning becomes more complicated because, in the worst-case scenario, running enough workers may become unprofitable even for ourselves.

More importantly, compared to a self-balancing approach (like sharing the revenues among worker operators) — the network growth is not responsive either to demand (and revenue growth) nor to the amount of stored data. The only reason for it to grow is manually increasing the rewards. Therefore, it would take a lot of accounting effort from us to ensure that we're not onboarding too much workers when the revenues don't cover the costs (even partially) anymore, but there are enough workers to serve the data to the clients.

It seems that rSQD is not going to work anyway for legal reasons so we will have to pay stables. Now there are two options:

• Redistribute the revenue from the loans directly (will likely be ~0 for quite some time before the network kick off)
• Pay from the treasury (and seed with some initial usdt capital)

I like the approach that Eldar suggested — instead of directly funding all the existing workers, use the real client-worker reward distribution flow (when we have it) and fund the system on behalf of the clients, generating the traffic. This way we can gradually start encouraging better-performing and useful workers instead of paying only for the uptime. Plus, if implemented correctly, it will automatically make the network stop growing when there are already too many resources.

Currently, many (if not most) workers are very slow or unreliable, but they are paid out approx the same amounts as the most performant ones. E.g., it's possible to run a worker that only downloads the data chunk when it's requested — it will be very slow, but should be enough to get the rewards.