About Paxos Standard (PAX)
Paxos recently launched the first regulated stablecoin, Paxos Standard Token (PAX). Like many recent tokens in the space, including stablecoins Tether and TrueUSD, PAX was created as an ERC-20 token on the Ethereum network, allowing for easy adoption and interoperability with existing wallets and exchanges. This blog post discusses the design of the PAX ethereum smart contracts with an emphasis on our minimalist contract design philosophy.
Developing on the Ethereum Virtual Machine (EVM)
Smart contract development on the Ethereum Virtual Machine (EVM) is a rapidly changing space with a fraught history of stolen assets and stuck funds. Independent third-party audits have become the standard to help alleviate the risks posed by public, immutable code that controls large amounts of assets. In addition, smart contract upgradeability patterns have become the recommendation by the community to allow for the ability to respond to any sudden bugs found in the EVM itself or in common contract patterns that were once thought safe.
The Design Principles Behind Our Smart Contracts
The Paxos Standard smart contracts were developed in-house by the Paxos Engineering team. Our team focused on creating an asset built on the most mature and well-tested smart contract code. Above all, we emphasized minimizing on-chain risk surface. We implemented multi-sig security off-chain instead of in smart contracts that might be subject to bugs in the Ethereum network. Additionally, the smart contracts are designed to be as simple as possible, and to use standard patterns where available.
Building a Secure Contract to Minimize Threats
All this uncertainty and potential threat vectors led us to do our very best to limit our smart contract threat exposure. This guided our choice to write simple, maximally upgradeable token contracts, as well as our choice to solve cryptographic multi-sig off-chain.
There is a tradeoff between making a smart contract fully upgradeable and reducing the level of trust users must place in the contract administrator. We decided that because Paxos already must act as a trusted party in the system in its role as the fiat handler and token supply controller, we could adopt a robust upgradeability strategy without significantly impacting the trust model. Paxos will be fully able to react to any contract bugs or Ethereum bugs, while still minimizing the attack surface that it puts on the blockchain.
Comparing PAX With Alternatives
When writing the Paxos Standard smart contracts, we looked at other stablecoins like ERC-20 Tether and TrueUSD. However, the PAX contracts differ from USDT, TUSD, and even GUSD (arguably the most similar token to ours) in some significant ways. First, all of these tokens only allow upgrading the basic token methods. EVM bugs affecting the administrative aspects of those contracts would be largely stuck the way they are, forcing their entire network to rebuild the token at a different contract address. This is costly, confusing, and detrimental to the token’s utility. Paxos has the full ability to add functionality to the implementation contract through a smart contract upgrade. In addition, the only piece of the proxy contract that cannot be replaced in a downstream contract is the roughly 10 lines of delegation code. For instance, if the admin role was found to be vulnerable, it could be set to zero, making it inoperable, and it could be replaced by a different role on the implementation contract for controlling future contract upgrades. To understand more of the distinguishing pieces of the Paxos smart contracts, we need to address contract upgradeability patterns.
Allowing for Contract Upgradeability
Smart contracts are immutable – at least, their code is. But the ethereum blockchain runs by having the ability to change state, such as token balances, by appending new information to the chain. Smart contract upgradeability works by having a Proxy contract that holds a pointer to a contract that holds the actual contract logic. Upgrades happen by changing that pointer through a method call on the proxy contract.
The Paxos Standard Proxy Pattern
The proxy pattern used for Paxos Standard, termed Upgradeability using Unstructured Storage, is one of the simplest and safest approaches available. It utilizes a solidity feature that is unfamiliar from traditional programming: delegatecall. delegatecall runs the bytecode of another contract in the memory context of the calling contract. The idea, also part of the Eternal Storage upgradeability pattern, is that the entire truth (see below) of the contract is held on the eternal proxy contract itself, while the code to run is on an implementation contract.
The Proxy Holds the Storage
A notable difference between the PAX contracts and those of GUSD and TUSD is that PAX uses the proxy itself to hold the token balances – and all other contract data. The alternative is a pattern involving a storage contract. In this case, an upgrade involves pointing the proxy to a new impl and pointing the impl to the storage contract, which never changes. Our basic reaction to this pattern is that while it nicely separates the concepts of proxy and storage, it introduces more in-contract complexity, such as new roles and authentication for the storage contract, which complicates zero-downtime upgrades and lowers audit confidence.
Enhancing Security with a Cyrptographic Multi-signature Scheme
Our choice of wallet pattern is another way that the Paxos Standard team has been extra careful with the Ethereum blockchain. Since the Ethereum community has yet to settle on a standard for contract multi-sig, we are reticent to risk using an unproven technology for cryptographic access control to customer funds. Instead, we have designed and developed a completely offline multi-sig scheme that allows for increased security, visibility, and a vastly reduced threat vector.
Using Shamir’s secret sharing and multi-layer encryption, we devised a way to ensure that keys can be distributed to signers without the fear of losing access to a key or the consequences of exposing a shard. To reduce the chances of collusion by internal bad actors, the process by which we reconstitute a key is auditable through off-chain cryptographic multi-sig. We have also assigned the roles of the smart contract to different groups of stakeholders varying by potential security threats. Lastly, in the event of any breaches, we have built the capability to address such issues into the PAX smart contracts through the proxy design, as already discussed, in order to resolve malicious activity ensuring the security of our funds.
Supporting More Decimal Places to Support More Use Cases
A final distinguishing piece of the PAX contracts is the choice of how many decimals to support. This is a seemingly simple decision, but an important one for a ground-breaking digital asset. The next generation of programmable money is expected to support micropayments and short-term low-interest loans to allow for new markets built on easy-flowing assets. Tokens like Tether and the Gemini Dollar follow traditional currency standards with support for only 2 decimal places, but we believe this is short-sighted. To support more sophisticated use cases Paxos Standard Token (PAX) is counted out to 18 decimal places – just like Ethereum itself.
Maximizing Simplicity While Minimizing Risk with Paxos Standard
The Paxos Standard smart contracts are as simple as we could make them. Our objective was to minimize risk through simplicity, shifting complexity off-chain wherever possible. We achieved this with a basic Upgradeability proxy model and offline secret sharding to make a next-generation asset that our users can trust. We hope you can find some inspiration in our smart contract design decisions as you go out to build awesome things on the blockchain – maybe even an application on top of the Paxos Standard Token!