This document provides technical details for PV01 bond smart contracts, in particular the on-chain software components. The associated off-chain software, including in-house APIs, 3rd party APIs and the Pivio platform are not in scope. For details on the PV01 vault smart contracts see the PV01 perpetual vault whitepaper.
All contract source code is available in Etherscan at the deployed contract addresses listed in the last section. All bespoke source code developed by PV01 is licensed under Business Source License 1.1 and is not an open source license.
The bond smart contracts are used to allow the issuing of debt on-chain. Each bond issued is a distinct ERC-20 smart contract. Each ERC-20 contract represents a debt claim (against the issuer) secured by an off-chain Treasury bill. Investors can purchase these ERC-20 tokens for USDC and redeem them for USDC at maturity.
The diagram below shows the logical implementation for PV01 bond contracts on EVM chains.
It shows a Bond Factory contract producing a bond of a given type (e.g. “SinglePaymentBond”) and version (e.g. “2”). Each bond is deployed as a separate ERC-20 compliant contract. For longer lived contracts, see the rTBL token in the PV01 Perpetual Vault. A bond has an Address Screen contract that enforces transfer restrictions. The Address Screen contract can be shared by many bonds and makes use of internal PV01 allow and deny lists as well as the Chainalysis Sanctions oracle contract.
PV01 Bond Contract Architecture on EVM Chains
For clarity, the above diagram makes some simplifications. The standard OpenZeppelin contracts and functions relating to Ownable, ERC-20 and ERC-165 are not shown. The bond proxy/implementation relationship is not shown and is explained in the Physical Architecture section below.
All on-chain state changes emit appropriate contract events to allow off-chain monitoring. These are not shown in the diagram.
The physical architecture is very close to the logical architecture above. The main difference is that the Bond Factory deploys a minimal proxy contract that holds storage and points to an implementation contract for its logic. This proxy uses the OpenZeppelin implementation of ERC-1167, where the minimal proxy is referred to as a “clone”. This is done to reduce bond contract deployment costs.
In practice, bond implementation contracts are deployed one per bond type and bond version pair. These contracts are then registered with the Bond Factory contract. At bond deployment time an appropriate implementation is then selected. The term “bond contract” refers to the minimal proxy contract/clone contract address, but functionally it behaves as if the contract were deployed using the complete implementation contract.
The bond contract is not upgradeable. Since T-bill bonds are relatively short-lived and have relatively simple business logic, they do not warrant the additional security overhead of being upgradeable.
The design goals are, in order of priority: