Decaying Capital Gains Tax in Curation Market

[Brandon]

Motivation

This proposal aims to address some of the issues highlighted in the Dynamic Curation Tax and Curator Impressions threads. Specifically, it aims to mitigate the steady-state incentive to front-run and pump-and-dump and any other tactics that reward an attacker for behaviors that are counter to the purpose of curation, which is to act as a prediction market for high-quality subgraphs.

Unlike the Showroom and Dynamic Curation Tax proposals, this aims to mitigate harmful behavior in the steady-state, not just when a subgraph is newly deployed. And unlike the Dynamic Curation Tax proposal, it seeks to do this without extracting any value from the curation mechanism, which we might expect to introduce a deadweight loss.

How it works

This proposal introduces a decaying capital gains tax. It works as follows:

1. When a Curator mints shares in the bonding curve, update the Curator’s cost basis and time basis for the bonding curve.
   • The time basis is the stake-weighted average purchase time of the Curator’s shares in the bonding curve.
   • The cost basis is the stake-weighted average per-share cost of the Curator’s shares in the bonding curve.
2. When a Curator burns shares in the bonding curve, compute their profit and holding time.
   • profit is computed as the GRT received when burning shares minus the aggregated cost basis of the shares sold.
   • holding time is computed as the time at which the shares were sold minus the Curator’s time basis.
3. Tax the profits (capital gains) according to how long the holding time is, and return the collected revenue back into the reserves of the bonding curve.
   • Profits that were earned over the course of a block should be taxed close to 100%
   • Profits that were earned over an arbitrarily long period of time should be taxed close to 0%.
   • Can explore the use of different decay functions. The prototype linked below shows a linear decay period where the capital gains tax decreases linearly from 100% to 0% over the course of a decay period.

The effect of this is that behavior that would generate profits over very short time periods–such as most forms of front-running, sandwich attacks, and pump and dump schemes–are no longer profitable, while behaviors that generate profits over a longer period of time, such as signaling on a subgraph that goes onto become widely used and generates query fees for the network, continue to be incentivized.

The immediate effect of this might be to decrease overall Curation activity as a large portion of the activity during the network’s bootstrapping phase appears to be motivated by trying to earn these short-term profits through anti-social behaviors.

Prototype

I developed a prototype in this Observable HQ Notebook alongside prototypes of other ideas that have been put forth in the forums.

Since the notebook is only lightly commented at the moment, I recorded some quick Loom videos to walk through an overview of the prototypes:

• Notebook Overview - This video gives a brief overview of how the notebook is structured as well as how to run the simulations.
• Decaying Capital Gains Tax Walkthrough - This walks through the decaying capital gains tax prototype specifically in a bit more depth, as well as some of the related results from the simulations.

I’ll note that in the sandwich attack simulation included in the notebook, where we assume the attacker has 10x the budget of the honest Curator, and the sandwich attack happens over several consecutive blocks, the profitability of the attack is reduced by 99.998%. These precise results will vary based on how the simulation is configured, but it’s fair to say that the profitability of short-term profit-making is decreased dramatically in all cases.

Open Questions

• Should the decay from 100% to 0% be linear or use some other decay function that drops off more sharply as a function of holding time?
• How long should the decay period last? Alternatively, over what time periods should profit-making be more heavily or less heavily rewarded?
• What are the additional gas costs imposed by tracking cost basis and time basis on each mint, as well as computing the capital gains tax on each burn?
• Since Curation shares are ERC-20’s how should the cost basis and time basis bookkeeping be extended to support token transfers?

Next Steps

• @ari has kindly agreed to use the above prototype as a starting point for evaluating such a mechanism.
• If the gas costs are acceptable, and the community can get behind such a proposal, then we can put this into a GIP.

[Ohmyjog]

I’ve been following your work on this - first of, thank you for all of your hard work in addressing these issues!

I have made it known before that I am not technologically inclined, but nonetheless I did ATTEMPT to fork this notebook… unsuccessfully.

I believe that this shows some tremendous upside potential. The tax redistribution back into the reserve side of the bonding curve will undoubtedly help with the initial launch portion of a Subgraph. Since I couldn’t figure out how to manipulate the notebook myself - have you experimented with any different time durations?

[Josh-StreamingFast]

While I really like the idea of the decaying capital gains tax, I am having trouble intuitively following a couple of cases I can imagine happening.

1. CuratorA apes in at T0. They are the only one signalling for a few days. Three days later, T3, CuratorB likes the subgraph and signals as well. After some period of time, a new subgraph is deployed that covers a lot of the same things, but (let’s imagine) the dapp devs have given their blessing on. Curators A and B were the only 2 to signal on this subgraph.

CuratorA sells their shares, incurring some of the tax on their profits, which remain within the pool.
CuratorB also sells their shares, incurring even higher tax due to their lower time curating, leaving some tax behind as well.

There is now a pool with no Curators, but some GRT, correct? Can this be avoided with checks on if you’re the final Curator in a pool? Will this create new and weird game theory dynamics as the amount of Curators on a subgraph decrease?

2. (This isn’t so much a scenario, but more a broad question) Is there perhaps a reason to actually set the time basis based on a second Curator minting shares? As it stands, depending on the length and strength of the decay, an “Extractor Curator” (for lack of better term) is still incentivized to ape in immediately, as this will set their decay clock as soon as possible. If other “Honest Curators” see value in the Subgraph, they’ll take their time to evaluate, and perhaps signal at a later date. Once that happens, ExtractorCurator will be “first in line” to extract profits, as their tax level will be (possibly) much lower.

Of course, the problem with using a second account to “start the timer” just creates an opportunity for Sybil to come in, but this may bring up the idea of also utilizing size of signal as a factor too. This may be over complicating the thing though, and I’m quite aware of that.

I have no perfect vision of that 2nd issue in my head as of yet, but I wanted to get the idea out there for discussion.

[DataNexus]

@Josh-StreamingFast

1. CuratorA apes in at T0. They are the only one signalling for a few days. Three days later, T3, CuratorB likes the subgraph and signals as well. After some period of time, a new subgraph is deployed that covers a lot of the same things, but (let’s imagine) the dapp devs have given their blessing on. Curators A and B were the only 2 to signal on this subgraph.

CuratorA sells their shares, incurring some of the tax on their profits, which remain within the pool.
CuratorB also sells their shares, incurring even higher tax due to their lower time curating, leaving some tax behind as well.

In this example, curator A would be at a profit (assuming we’re through the initialization phase from the showroom proposal) and would be taxed a percentage of his profit and would keep the untaxed portion. Curator A’s untaxed profit would also be Curator B’s loss and curator B could unsignal without capital gains as there was no realized profit.

If the subgraph received significant query fees during this time there is a possibility that curator B could also be at a net profit, at which point a catch for avoiding capital gains is appropriate when flattening (or deprecating) a bonding curve.

@Josh-StreamingFast

2. (This isn’t so much a scenario, but more a broad question) Is there perhaps a reason to actually set the time basis based on a second Curator minting shares? As it stands, depending on the length and strength of the decay, an “Extractor Curator” (for lack of better term) is still incentivized to ape in immediately, as this will set their decay clock as soon as possible. If other “Honest Curators” see value in the Subgraph, they’ll take their time to evaluate, and perhaps signal at a later date. Once that happens, ExtractorCurator will be “first in line” to extract profits, as their tax level will be (possibly) much lower.

This behavior will likely be seen if we set the decay period too short. Slimchance and I have discussed a period of 3/6 months depending on how long the initialization exit phase would be in the showroom proposal (the two should likely work hand in hand for a fully fair launch of a new GNS).

[DataNexus]

@Brandon

Open Questions

• How long should the decay period last? Alternatively, over what time periods should profit-making be more heavily or less heavily rewarded?
• Since Curation shares are ERC-20’s how should the cost basis and time basis bookkeeping be extended to support token transfers?

• The decay period should last over 3-6 months. With too short of a time period we will still be open to attacks. This period likely should coincide with a GNS initialization exit phase on the showroom proposal to compliment a fully fair launch, even though this is applicable through the lifespan of the GNS (clock starts at the point of signal). I believe signal is a communication system between developers/curators to indexers to accurately predict the next 1-2 quarters worth of growth in the web3 space.

• If the ERC-20 token is transfered, this should be received with a timebasis of the transaction timestamp. In regards to the cost basis I think for simplicity if it was sent using a transfer function the cost basis should be set at 0 since they accurately received it for nothing.