Spamming the PRIA airdrop list for fun and profit

I spent most of the day working on $PRIA related things today, mostly trying to figure out how to read data from the smart contract using Alchemy. I learned a lot.

I bought a few more tokens this morning to try and get back on the airdrop list, but I miscalculated the threshold and messed up. So I’ve decided to codify the calculations to figure out whether initiating a transfer will work as a way to cheaply accumulate the tokens. A transfer costs more gas than a standard Ethereum transfer call because of the airdrop code called by the function.

By checking the balance of the airdrop address each time it changes, one can estimate the airdrop amount. It’s roughly 1/200th of the total amount, and changes depending on the ratio of the airdrop wallet balance and the total market cap.

The next step involves estimating the gas needed for a transfer. I haven’t gotten this far, but it’s part of the web3 framework. I could also run a test transaction myself. Most of the transactions happening right now are interacting with the uniswap router, so it’s not accurate. Right now the floor seems to be about 400,000 wei, or about $3.51 in Eth.

In fact, as I write this, with the cost of PRIA just over two dollars, I could transfer the amount to myself, and potentially get back $0.50 worth of PRIA as a reward.

Of course, the tokenomics come into play here. I’d lose some PRIA on each transfer, increasing the burn amount with each transaction. Then I’d have to wait for another two hundred transactions to come through before I get my reward, before I can sell it. Then there’s also the question of selling.

I was able to put something together in a spreadsheet to figure things out. With the current burn rate, one can self-transfer the minimum amount of PRIA needed to qualify for the airdrop and spam one’s address to the payout list, taking up all 200 spots. A the current cycle, with the burn rate at 2.6% and about 600 PRIA in the airdrop pool, it will cost you less than six PRIA and drain the airdrop balance by roughly half. At this point one sits and waits for the next two hundred transactions, which which will payback at least 155 PRIA. This number is calculated on an additional 200 minimum qualifying transactions, which will continue to drain the airdrop balance.

The big problem though, is the gas fees. Spamming two hundred transactions will cost a lot. I calculated it as about two times as much Ether than the expected payout.

Of course, this is a dynamic system. Prices change, and everytime the system cycles through the airdrop list the burn rate changes. So, I’m in the process of building a script that can pull this data in real time and do the computations. Here’s the basic outline:

Monitor airdrop address for balance changes. This can be done with Alchemy's notify webhooks. 
Get the burn rate from contract
Get current current gas cost
Get PRIA price, either from Uniswap directly or via CoinGecko API
Calculate the wash trade costs (in PRIA) and expected payout
Estimate gas usage for transfer function
Compare gas fees to expected minimum payout. 
If profitable, execute 200 self-transfers
Wait for payout, then execute Uniswap exchange

There are several risks here.

First off, the calculation for the self-transfer needs to be perfect. If it’s too low, the payment won’t qualify for the airdrop list. If it’s too high, you’ll lose more than needed to the burn function.

Next, the gas calculations are tricky. PRIA transfers require much more gas than standard ERC20 token transfers, due to the airdrop system itself. Additionally there are rate adjust functions that are triggered on turn one of the airdrop cycle. And there’s additional functions that are called at the end of each turn when PRIA hits a floor or ceiling and swaps from burn to mint. I might be able to more accurately predict the fees. I could pull the gas costs from previous airdrop payout transactions, but I’m not sure if I could, filter out all the Uniswap interactions from those. More likely, I’ll need to deploy PRIA on an internal testnet, and spam the list for a couple cycles to take an average.

Then, there’s the risk that the price dumps before the next cycle completes. One could mitigate this risk by cycling the airdrop list for two whole cycles. It would increase the gas prices by double, plus an additional percentage that I haven’t calculated yet. Theoretically though, there is a point where the price of PRIA can get high enough, and gas prices low enough, that one could pay for such a double airdrop spam cycle, cover the cost by selling, then sit back and wait for the next two hundred transactions to trigger airdrop rewards at a profit.

That said, I have no idea how to do any of this. I’m trying to learn Javascript and web3 at the same time right now. I could use the Python library, but having a basic knowledge of how JS promises and async functions work is something I need to know. I’ve been able to pull data from the blockchain and have done some quick models in a spreadsheet, but there’s so much I have to figure out from there. I have a lot more questions that I have to figure out from a design standpoint, not to mention all the testing and data modeling that I can do from here.

And who’s to say even if I build it that we’ll even reach the point where this will work. PRIA’s less than a week old at this point, but I’m not sure if it’s ever going to reach the point where it’ll work, or whether it’ll peter off and die. All the work that I’m doing will be useful though, as the skills I’m using will make me a better engineer.

What if I could build something that could watch the blockchain, and when the moment’s right, fire off four hundred self transfers, take the resulting income and Uniswap it in one block. Wouldn’t that be glorious?

It might just work. Unless it gets frontrun.