Quick PRIA Update

Spent some more time working on TheGraph today. Managed to get a subgraph up that shows PRIA transfers. I’ve got to study GraphQL to figure out how to use this, and modify the schema to make it usable. I think a lot of people want to see the top holders by address, and I’d like there to be a way to query the top burnable addresses. I thought of an incentive app that would use these results and allow people to push a button to sign a transaction to burn them, whilst reimbursing them for the gas plus a bonus.

It sounds like something that could be done, although it might need another contract deployed to pull it off properly. These kind of proposals should be voted on by the community, so I really think the first order of business is some kind of DAO or other voting mechanism among PRIA LP providers. If you’ve got experience with doing so, let me know.

Right now the liquidity pool is the only safe haven for tokens, but given the possibility for divergence loss during the run up, there might need to be a better way to incentivize liquidity. That also brings up another point as well: the deflationary phase might cause additional divergence, but on a net positive on the Eth side. The way I understand it, the Uniswap stake loses ETH value compared to hodling as the price appreciates, but loses value slower as the price depreciates. This needs further exploration before I can speak with certainty.

Image for post
The above chart shows an ETH/DAI pairing. Source: Understanding Uniswap Returns

It looks like there are many ways to play this game, and the more time I spend on it the more avenues I see.

I’m not gonna shill given all the uncertainty in the market, especially given the fact that US elections are less than a week away. That said, I’m pleasantly glad to see that PRIA is holding up well. There seems to be healthy liquidity and volume, and the TG/CT communities are pretty active. And we’re not even at 80k supply yet!

Source: Uniswap pair info

That said, my main holdings are still in BTC, and to a smaller extent, ETH. I’m very anxious about the election and what effects it’s having and will continue to have over the next few weeks. I’ve spent the last few months exiting from traditional equities, AMZN, NVIDA, TSLA, hoarding cash in anticipation of a buying opportunity. This week’s pullback, caused by lockdowns in Europe, no sign to COVID cases in US, and failure to launch a second stimulus package, was enough for me to pull the trigger. I’m all in.

So right now, a majority of holdings are in BTC, but I’ve got even more in my tax advantaged retirement account that is in Grayscales GBTC, ETHE, and GDLC products. I’ve also got mining companies like CAN, RIOT, and MARA, and Canadian-based exchange Voyager.

My bags are packed. Now I just need to sleep for a year.

PRIA explainer webcast

I finally got around to doing a $PRIA explainer video with @EnderleTres, A.K.A CryptoDaddio last night. We talked for about a half hour.

I didn’t want to dox myself. Instead of a disguise I wound up buying a copy of FaceRig, and made gave the interview as a Marvin The Martian type character. It came out all right. The program is pretty genius, although lighting, glasses and headset complicate the face tracking. The girls wouldn’t leave it alone while I was setting it up. There’s lots of princess models and anime characters.


And just to point out how Wild West crypto and DeFi is right now, just this morning I learned the Harvest.Finance got hacked for $25 million.

Harvest explained the attack here, and has moved to protect the other funds (thread).

And I know a lot of devs and hackers will be going through the history here to figure out how these flash loan attacks work.

Unpacking PRIA

Yesterday I was a bit of a mess, as I made the mistake of watching the presidential debate the night before and stayed up way too late. I’ve been doing very badly with my habits lately. I spent most of the day in a funk.

After I woke up, the first thing i did was checked the price of $PRIA. It was up another $20, and peaked at $83 early before settling back down. It’s quite the run over the last few days and has left me in a bit of an awkward position, of being in a winning position and indecisive about what to do next.

There was a flurry of activity in the Telegram group, and a load of drama after someone decided to copy and paste the PRIA token contract code into another token. They called it a fork, but they didn’t know what they were doing. For one, they didn’t change the date that allowed one to burn the owner functions, like setting the airdrop address and exempting the Uniswap pools from the inactivity burn. Dr. Mantis, the creator of PRIA, saw this and pulled the killswitch, and banned a bunch of people from the Telegram group as a result.

Despite my inability to focus yesterday, I did manage to get some work for Zombie, LLC, and I did continue coding on my PRIA bot. At this point I’m not sure that my strategy will ever be profitable, since others seem to be running some sort of similar strategy. I’m having some trouble with dependencies in my Node project, and am running into some issues with the fact that I seem to have wound up with both web3 and ethers, and am having some bugs due to there being several big number packages in the modules, one of which seems to be an older version. I thought that I would be able to simulate the PRIA contract code in Javascript in order to get an accurate payout of the airdrop as it cycles to the next two hundred slots, but achieving precision is proving difficult.

My involvement with the project is also making me somewhat uncomfortable. I got involved cause I wanted to understand the contract code, and I seem to have put myself the position of being a community leader. I’ve been messaging with the creator constantly with questions about how things work, and have been answering questions in the group to explain how things work. I have been rewarded eight times over what I initially put in as a test.

As a result I’m basically looking at a month’s salary for the last week’s efforts. And the truth is, I am still very skeptical about this project. It’s about a tenth of the way through this turn one burn cycle, and despite the flurry of activity, I’m still not convinced it has enough gas to get there and back, let alone all the way through one of these “ultracycles”. Some of the moonboy chatter that I’m seeing is not really anything I want to be associated with, and I feel like I’m in a very, very tough spot.

When it comes down to it, PRIA is a game, and it’s an insanely complicated one. People are throwing numbers out like $100 or $1000 or higher, and one of the problems I have is that there are many, many fresh faces that are coming in here trying to get on board with this. I’m gauging my assessment based on the number of Twitter followers that I see shilling.

I don’t want to be a part of it, but I already am a part of it, so what do I do about that?

Two nights ago, during the debate, I was in telegram chat trying to make some of these concerns known, trying to advise caution. At one point I mentioned that the creator “erred” by not making the contract upgradable, and some people got really panicky. “Why admin FUD,” or “why mod FUD,” went up. A couple people, more experienced in the space I guess, DMed me to say they understood or agreed with me. My final word on the matter was that the project was going to survive or not in spite of what I had to say on the matter.

So I was a bit shocked when I woke up to see another twenty dollar pump.

I don’t want to do price projections, but I may as well. I’m paying attention to the ETH pair. We’ll see what it does here on the short term.

Chart via DexTools

The uptrend line hits 1:1 with ETH near the end of the month, which seems impossible, granted. If there’s a lot of volume that drives the supply down fast enough, it may drive the price upward, but I don’t think the trend is going to hold. This level does seem to be pretty good support, we’ll see if it holds or if we trend sideways for a while. The market cap has dropped from $5.2 million down to $4.2, and with the supply floor on this turn set to 10,000 PRIA, does that mean that we could see $400-500 PRIA?

I’m not sure, but for now, I’m content to let my bags sit for a few more days and see what happens. This turn might take a while, and we’ll see how things go for now.


Finally, a quick look at the weekly $BTC chart, just for a bit of perspective. We’ve got another day and a half to close this last candle, which could be the highest weekly close since November 27, 2017.

Wash trading PRIA for airdrop slots

Things are nuts right now.

I’ve spent most of my time thinking about PRIA and how to game it. I there’s a way to compute the minimum future airdrop payout. By comparing that to the current price and gas costs of a transaction, one can sell the future payout for ETH, burn that eth for gas on a transfer, and will be guaranteed at least the same amount of PRIA back in a future airdrop, two hundred blocks later. That’s the plan at least.

I’m still working out the calculations. I can only estimate the gas as this point, and I’ve still got to simulate the transfer cost, which includes burn, treasury and airdrop fees. This holds increases at some point during the airdrop cycle, so the question is whether I code this up in the main Javascript module that I’m creating, or set up an actual contract in Truffle that I can run it against. I’m not sure yet.

What I do know is I woke up this morning to find a huge run up on price. Gas costs are still high enough that it means flooding the airdrop queue will cost more than the ultimate payout, but if one assumes that PRIAs deflationary price action will continue, then one may be willing to risk more.

We’re also talking profitability from a minimum future payout. One can assume that the actual future payout will be higher than the minimum, since any transaction with a fee larger than the airdrop payout will increase the airdrop balance, not drain it.

I have also determined that flooding the entire airdrop queue in one transaction is likely impossible, due to gas costs, and I believe the upper bound is around 20 at a time. Still, I should be possible to sell PRIA on Uniswap, and self transfer enough to qualify for a spot on the queue in one transaction. One could cover gas costs, and insure that you get back at least as much as the total costs, both the gas fees and any transfer funds.

This process would theoretically allow someone to accumulate PRIA with zero capital risk. They would basically be arbitraging the costs now for the expected payout on the next airdrop cycle.

$PRIA price chart

On top of all this, it looks like $BTC has crossed a critical threshold. I had to zoom out on the weekly to get a bit of perspective on this.

Not only have we broached the critical rsistance line at $12,060, but we’re also about to break through a multi-year uptrend support that was only breached by the COVID-dump. We saw a little bit of action above this line a few months ago. And yes, I know these kinds of lines on a log scale aren’t sustainable, but it’s clear to me that we are in a bull market.

The orange line at the top is a moving profit-taking target based on the Mayer Multiple, the factor of price to the 200-day moving average. I calculated the 2017 peak to be around 2.8 times, so when we get to that price level, I plan to take some profits.

I had that feeling this morning that things were happening. Recently, I saw a Tweet that said if you feel like bragging, then it’s time to sell.

I’m starting to feel that way right now.

Calling Ethereum contract methods in Javascript

I am still trying to wrap my head around Javascript’s Promises and how to use them properly. I did make some progress today and managed to get some data off of the PRIA contract using web3.

A lot of my confusion stems from the behavior of the JS arrow function. I now understand it in relation to a Python lambda function. And now that I’ve figured out how to create an anonymous async function in Javascript, I think I’ve opened another door in my mind that is going to make this a bit easier to work with. I feel like I’ve leveled up.

I’ve create a small class that I can use to pull the data from the chain. I’m using Alchemy’s API to do this, my key is stored in an .env file.

// pria.js

require('dotenv').config()

const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
const web3 = createAlchemyWeb3(process.env.ALCHEMY_URL);
const priaContract = "0xb9871cb10738eada636432e86fc0cb920dc3de24";
const PRIA_ABI = [{"OMITTED FOR BREVITY"}] // copied from Remix or Etherscan

class Pria {
    constructor() {
        this.contract = web3.eth.Contract(PRIA_ABI, priaContract);
        this.airdrop_threshold = "2500000000000000";

        (async () => {
            await this.init();
            console.log(this.airdropAddressCount);
            console.log(this.burnRate);
            console.log(this.minimumForAirdrop);
            console.log(this.totalSupply);
            console.log(this.tx_n);
        })();
    }

    async init() {
        this.airdropAddressCount = await this.contract.methods.airdropAddressCount().call();
        this.burnRate = await this.contract.methods.burnRate().call();
        this.minimumForAirdrop = await this.contract.methods.minimum_for_airdrop().call();
        this.totalSupply = await this.contract.methods.totalSupply().call();
        this.tx_n = await this.contract.methods.tx_n().call();
        return true;
    }
}

There are various ways to call async functions from a class constructor. I’m probably not doing it very elegantly, but I think I understand the how to use immediately invoked function expressions. These self-executing anonymous functions remind me a lot of Lisp and lambda calculus.

I’ll be using the Pria class within additional code to calculate the cost of spamming the PRIA airdrop list as I described earlier. There are additional state variables that I need to retrieve from the contract. These aren’t public, so I’ll have to do some more hacking to pull them directly from storage, after I figure out where to look.

Once that’s done I’ll have my application logic code compute the cost of two hundred transactions and compute the price to dump all the gained tokens on Uniswap. Then the exciting part will be waiting for it to become profitable.

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.

PRIA: Ethereum game theory tokenomics

An interesting token experiment, called $PRIA, popped in my feed today. It was launched two days ago by an anon dev called Dr. Mantis operating under an operation called DeFi LABS. It’s described thus:

PRIA is a fully automated and decentralized digital asset that implements and manages a perpetual ultra-deflationary monetary policy favourable to inflation arbitrage by market participants.

Source: PRIA.network

Now that’s mouthful, what does it mean? I spent most of today going through the smart contract code to figure out exactly what’s going on, and also to make sure there’s nothing going on that isn’t supposed to be there. Here’s a rundown.

Tokenomics

PRIA’s supply is controlled by it’s smart contract. It starts at a ceiling of 100,000 tokens, and a percent is burned as part of each transfer. Eventually, the supply will reach a floor of 10,000, at which point a turn will have completed, and the process will reverse. The floor and ceilings will decrease each turn, until they bottom out at 12 and 1.25 PRIA tokens. This will complete the macro contraction, at which case it goes into an expansion phase, and back and forth ad infinitum.

Source: http://pria.eth.link/

The burn and mint percentages are adjusted for every transactions. The contract source code is below. (I’ve added some comments.)

def _rateadj() -> bool:
# Adjust each tx
    if self.isBurning == True:
        self.burn_pct += self.burn_pct / 10
        self.mint_pct += self.mint_pct / 10
        self.airdrop_pct += self.airdrop_pct / 10
        self.treasury_pct += self.treasury_pct / 10
    else:
        self.burn_pct -= self.burn_pct / 10
        self.mint_pct += self.mint_pct / 10
        self.airdrop_pct -= self.airdrop_pct / 10
        self.treasury_pct -= self.treasury_pct / 10

# Circuit breakers for individual rates 
    if self.burn_pct > self.onepct * 6:
        self.burn_pct -= self.onepct * 2

    if self.mint_pct > self.onepct * 6:
        self.mint_pct -= self.onepct * 2

    if self.airdrop_pct > self.onepct * 3:
        self.airdrop_pct -= self.onepct
    
    if self.treasury_pct > self.onepct * 3: 
        self.treasury_pct -= self.onepct

# Across the board reset if rates get too low. 
    if self.burn_pct < self.onepct or self.mint_pct < self.onepct or self.airdrop_pct < self.onepct/2:
        deciCalc: decimal = convert(10 ** self.decimals, decimal)
        self.mint_pct = convert(0.0125 * deciCalc, uint256)
        self.burn_pct = convert(0.0125 * deciCalc, uint256)
        self.airdrop_pct = convert(0.0085 * deciCalc, uint256)
        self.treasury_pct = convert(0.0050 * deciCalc, uint256)
    return True

Rewards

There’s another piece to this token, the airdrop. You’ll notice in the code above that there’s an airdrop rate. The contract’s transfer function contains code which subtracts or adds the burn/mint amount, minus the treasury and airdrop fees. Then airdropProcess is called.

@internal
def airdropProcess(_amount: uint256, _txorigin: address, _sender: address, _receiver: address) -> bool:
    self.minimum_for_airdrop = self._pctCalc_minusScale(self.balanceOf[self.airdrop_address], self.airdrop_threshold)
    if _amount >= self.minimum_for_airdrop:
        #checking if the sender is a contract address
        if _txorigin.is_contract == False:
            self.airdrop_address_toList = _txorigin
        else:
            if _sender.is_contract == True:
                self.airdrop_address_toList = _receiver
            else:
                self.airdrop_address_toList = _sender

        if self.firstrun == True:
            if self.airdropAddressCount < 199:
                self.airdropQualifiedAddresses[self.airdropAddressCount] = self.airdrop_address_toList
                self.airdropAddressCount += 1
            elif self.airdropAddressCount == 199:
                self.firstrun = False
                self.airdropQualifiedAddresses[self.airdropAddressCount] = self.airdrop_address_toList
                self.airdropAddressCount = 0
                self._airdrop()
                self.airdropAddressCount += 1
        else:
            if self.airdropAddressCount < 199:
                self._airdrop()
                self.airdropQualifiedAddresses[self.airdropAddressCount] = self.airdrop_address_toList
                self.airdropAddressCount += 1
            elif self.airdropAddressCount == 199:
                self._airdrop()
                self.airdropQualifiedAddresses[self.airdropAddressCount] = self.airdrop_address_toList
                self.airdropAddressCount = 0
    return True

What’s happening here first is a check whether the transaction amount meets the threshold, which is a percentage of the airdrop account balance. If true, sender’s, or receiver’s in the case of a contract interaction, address gets added to a list of two hundred approved addresses. Once this list is filled, the air drop process starts, and the first account on the list is rewarded with the actual airdrop.

In this implementation, the airdropAddressCount cycles to 199 and is reset to 0. Apparently Vyper doesn’t support queues.

@internal
def _airdrop() -> bool:
    onepct_supply: uint256 = self._pctCalc_minusScale(self.total_supply, self.onepct)
    split: uint256 = 0
    if self.balanceOf[self.airdrop_address] <= onepct_supply:
        split = self.balanceOf[self.airdrop_address] / 250
    elif self.balanceOf[self.airdrop_address] > onepct_supply*2:
        split = self.balanceOf[self.airdrop_address] / 180
    else:
        split = self.balanceOf[self.airdrop_address] / 220
    
    if self.balanceOf[self.airdrop_address] - split > 0:
        self.balanceOf[self.airdrop_address] -= split
        self.balanceOf[self.airdropQualifiedAddresses[self.airdropAddressCount]] += split
        self.lastTXtime[self.airdrop_address] = block.timestamp
        self.lastLT_TXtime[self.airdrop_address] = block.timestamp
        self.lastST_TXtime[self.airdrop_address] = block.timestamp
        log Transfer(self.airdrop_address, self.airdropQualifiedAddresses[self.airdropAddressCount], split)
    return True

What’s of note here is that the airdrop reward, the split, fluctuates, depending on the airdrop account balance as a percentage of total supply. The split is:

One percent or less: 1/250 the airdrop balance
One to two percent: 1/220
Two or higher: 1/180

Note that this is independent of the actual airdrop_pct that is subtracted from each transaction.

Assessment

It’s an interesting project from a game theory perspective. I’m not usually interested in stuff like this, but I saw it being shilled and wanted to take a look and see if I could tell what’s going on. This is not a full security audit by any means, but I couldn’t make heads or tails of the project description and needed to delve into the contract to fully understand it.

A couple notes:

The contract is written in Vyper, which is an updated Ethereum VM language. It’s considered safer than Solidity, and focuses on code readability. There’s a lot of safety checks.

It’s also important to note that PRIA is an iteration on a previous project from Dr. Mantis, called Galore. I’m not keen on the details, but apparently there was an exploit within that code. Galore holders (258 total) were granted 75% of all PRIA tokens at launch. The rest went into the PRIA-ETH Uniswap pool, although it only holds some 16,000 tokens.

There are also a number of manager functions written in to the code. A few of these relate to the Galore passlist, and there are some others that set the Uniswap router and factory addresses. The last two functions consist of a burn function, which allows the owner to decrease the total supply by an arbitrary amount, and a manager_killswitch, which removes all of the manager functionality. This last function is locked until this Saturday, midnight GMT, at which point anyone can call it.

It is extremely critical because PRIA has a built in penalty for inactive accounts, a burn system. If an account hasn’t made a transaction within 35 days, then someone can call this burn function and wipe 25% of the balance on the account. After sixty days, the entire balance can be burned. There are burn similar rules for contracts as well. According to the smart contract, the Uniswap addresses are exempt from this calculation. Also, the airdrop address can be burned after a week, but the project would likely be dead before this happens.


So there’s a breakdown of my look at the smart contract code. Again, I’m not a professional code auditor, so take this as it may. It looks solid, although I’m not a hundred percent on the Uniswap aspects of it. There’s a small community of people on Twitter that are interested in this project, but I’m not sure how much interest it will garner. It’s an interesting concept, for sure.

The rules are complex, and may appeal to some with an interest in game theory, and I have no idea what will happen once the we get near the supply floor and things get tight. The burn penalty may move things along a bit, but still, it could be a very long time for one of PRIA’s ultra cycles to complete.

Will we see interest from the rest of CT FOMOing into this at some point and driving the token up in the $100 range? Possibly, although I’m not ready to make any long-term predictions. This may be an interesting pocket change game, and I did pick up a few PRIA myself, just to see what happens. (Beware gas Uniswap gas fees…)

One thing I can say for sure is that there are probably a lot of early players who are doing statistical modeling as we speak to figure out how this will all play out, and it could be that the only winner from this game will be Dr. Mantis.