In August 2023 Paypal unveiled their new stablecoin, an ERC20 token built on Ethereum. The code is open source, the contract is verified on Etherscan, it’s a real token which is going to be available to Paypal’s 435m users.
What Is pyUSD & How Does It Work
The Paypal stablecoin was developed in partnership with Paxos.
PYUSD is designed to have a stable value, with 1 PYUSD always equaling 1 USD. This stability is achieved by backing the cryptocurrency with secure, highly liquid assets such as US dollar deposits, US treasuries and cash equivalents.
Users can buy, sell, hold and transfer PayPal USD in the PayPal app or on the PayPal website. PYUSD can be sent to friends on PayPal without fees. It can also be sent to and from Ethereum wallet addresses. This could be a convenient on/off ramp for crypto users to spend digital assets anywhere that accepts the Paypal credit card.
PYUSD is built much like other centralized stablecoins such as USDC and USDT. It lives as a smart contract on a blockchain network. Let’s take a look at the code…
pyUSD Smart Contract Review
The contract is designed and managed by Paxos, under the legislative requirements of the New York Department of Financial Services. This means it is fully centralized and PYUSD balances can be frozen or seized. The contract is also upgradable via the standard proxy mechanism.
The code and security audit by trail of bits is here:
https://github.com/paxosglobal/pyusd-contract/tree/master
The contract is at:
https://etherscan.io/token/0x6c3ea9036406852006290770bedfcaba0e23a0e8#code
The first thing to note is the contract is using a very old version of solidity 0.4.24 which would suggest the code has been forked from something else.
The earliest code I could find which is very close to this is from 4 years ago by a project called TimesPay. Major exchange OKX also has the same code in a repository for it’s OKB token. Another developer suggested it was originally developed by Binance for BUSD but I haven’t been able to verify that.
Update 2023-08-08 The contract is based off Paxos USDP although I’m not sure if that predates the other projects discussed. Code source is 5 years old, latest implementation is 2 years old.
There’s pros and cons to forking an older contract, in some ways using an outdated solidity compiler comes with risk associated with known and unknown bugs however there’s also the lindy effect that the contract is proven secure and has been responsible for holding a huge amount of funds without any hacks.
Getting back to the code, if we look at the events for “asset protection” and the wipeFrozenAddress() function we can see that there is the ability for the admin to wipe 3rd party balances.
event AddressFrozen(address indexed addr);
event AddressUnfrozen(address indexed addr);
event FrozenAddressWiped(address indexed addr);
/**
* @dev Wipes the balance of a frozen address, and burns the tokens.
* @param _addr The new frozen address to wipe.
*/
function wipeFrozenAddress(address _addr) public onlyAssetProtectionRole {
require(frozen[_addr], "address is not frozen");
uint256 _balance = balances[_addr];
balances[_addr] = 0;
totalSupply_ = totalSupply_.sub(_balance);
emit FrozenAddressWiped(_addr);
emit SupplyDecreased(_addr, _balance);
emit Transfer(_addr, address(0), _balance);
}This isn’t ideal and is a long way from the decentralized permissionless standards we hope to benefit from in DeFi. It is also the same functionality that is encoded in USDC and USDT contracts as well, Paypal likely couldn’t create a truly decentralized permissionless product due to regulatory requirements.
On a positive note pyUSD includes beta functionality for gasless transfers via delegated transfers.
In order to allow for gas-less transactions we have implemented a variation of EIP-865. The public function betaDelegatedTransfer and betaDelegatedTransferBatch allow an approved party to transfer PYUSD on the end user’s behalf given a signed message from said user. Because EIP-865 is not finalized, all methods related to delegated transfers are prefixed by Beta. Only approved parties are allowed to transfer PYUSD on a user’s behalf because of potential attacks associated with signing messages. To mitigate some attacks, EIP-712 is implemented which provides a structured message to be displayed for verification when signing.
From the readme at: https://github.com/paxosglobal/pyusd-contract/tree/master
The contract uses OpenZeppelin libraries, it’s simple, robust and probably previously proven. Sensible and smart to use a tried and tested contract rather than trying to innovate but there’s not much to get excited about in the code.
The Implications For Paypal & DeFi
Paypal is a $70B+ company and for them to deploy a stablecoin on a public blockchain network is a big step forwards for the industry. I believe it may be the first signs of us approaching some form of regulatory maturity, as the tweet below suggests
This is what happens when we start to get regulatory clarity, and with the Payment Stablecoin Act, this can open up a free and competitive market for dollar stablecoin issuers with strong supervision, allowing the US to compete with digital dollars that are uniformly safe, transparent, liquid and supervised to Fed-standards.
– Jeremy Allaire*
Stablecoins are big business, USDC & USDT have a combined AUM of over $100B. The onchain tokens don’t cost anything to create and the dollars they custody are deposited into short term treasuries so they are earning somewhere in the region of 5% APR on that amount.
Consider that revenue stream in the context of expected growth within decentralized finance and you have the opportunity for very big businesses. If Paypal’s PYUSD can capture market share then there is potential for it to become a major part Paypal’s value as a company.
And who do you trust more to maintain a 1:1 peg and honor withdrawals, Circle, Tether or Paypal?
I don’t love the fact that PYUSD is a fully permissioned contract and the ability for the owners to delete balances at will removes some of the value in decentralized architecture.
The ideals that we strive for in permissionless code where all users are treated equally does not fit in to the current regulatory landscape, unfortunately. Maybe there is room for both permissioned and permissionless code on our public blockchains and users can decide which products they wish to use in the future.
