Category: Crypto

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.

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.