Considerations

We would recommend having a full read through of the Perennial mechanism to get a good idea of how things work. In this section, we'll call attention to some of the nuances of Perennial that developers may encounter.

USD Collateral Only

Perennial only allows for collateral in USD (namely, USDC/DSU) & all P&L is settled in the collateral account. See the Maintenance section for more info on collateral requirements.

However, developers can build on top of other borrow / lend protocols to use other tokens as collateral (ex. deposit ETH into compound, borrow USDC and deposit it as collateral on Perennial).

Delayed Settlement

In order to ensure the consistency & safety of the markets in Perennial, order settlement is delayed. While this increases complexity when it comes to integrating, the reduction in risk is worth it. To learn more about the settlement flow see the Settlement section.

Functionally, you can check the settlement of your pending position update by waiting for the timestamp that have been emitted by Updated() to be included in an oracle version. This can be checked by passing the timestamp to at(timestamp) function to the market's oracle and receiving a version back.

Failure to settle:

In rare circumstances settlement can fail. There are two possible scenarios when this can occur:

• Oracle has no price

• The keeper fails to commit a price within the required timeframe.

In this situation, all position updates for that epoch will need to be resubmitted.

Operators

Within the protocol, Operators are special entities that users can approve to control their accounts at the factory level. For market operations, the user must approve the Operator to the MarketFactory & for vaults, the VaultFactory. Once approved, operators can modify accounts for all across all markets or vaults owned by the approved factory contract.

Since operators act on behalf of users any bugs in the operator contract can effect all users that have approved it. Please ensure safe practices when building operators!

Operators allow for user experience enhancements while keeping the core functionality of the protocol streamlined. For example:

• An operator could allow users to batch operations using multicall[]

• An operator could add custom order types, executing market operation when conditions are met in the operator contract.

• An operator could consume signed market order to enable gasless transactions for its users.

An Operator could be a contract or an externally owned account. While it's in the spirit of the protocol to build an operator as contract, it is possible to have an EOA act as an Operator. This would greatly reduce transparency & push security assurances off chain, so be thoughtful when implementing such Operators.

Unmatched Markets

Though unlikely, it is possible for takers to not be matched 1:1 with makers (meaning taker exposure) would be less than 100%. See the Profit and Loss section for more info. Perennial has mechanisms & procedures internal & external to the protocol to prevent. And in the event it does occurs, it is likely to be extremely short-lived (arbitrageurs have a huge incentives to close the gap ASAP).