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.