# Valorem <> Zellic Audit Prep

Please provide us with the following

**A short description of your project. We will use this in the introduction of the audit report.**

The Valorem Options V1 Core consists of a settlement engine which allows users to write options, exercise options, and redeem claims on assets, while handling fair assignment of exercises to claims written. It is designed to be gas efficient, minimal, and provide a secure settlement layer upon which more complex systems can be built.

The Settlement Engine follows the ERC-1155 multi-token standard. Options can be written for any pair of valid ERC-20 assets (excluding rebasing, fee-on-transfer, and ERC-777 tokens). When written, an options contract is represented by semi-fungible Option tokens, which can be bought/sold/transferred between addresses like any ERC-1155 token.

An option writer's claim to the underlying asset(s) (if not exercised) and exercise asset(s) (if exercised) is represented by a non-fungible option lot Claim token. This Claim NFT can be redeemed for their share of the underlying plus exercise assets, based on currently exercised.

**Link to documentation:**

https://valorem.xyz/docs/smart-contracts-overview/#core-interface
https://github.com/valorem-labs-inc/valorem-core#building-the-project

**Commit hash:** 6c118f2090ba4f9ddac878a4afb1e5facb49b7ca

### Pre-audit questionnaire

**Give us a high level overview of what the system is meant to do?**
-

The Valorem Options V1 Core consists of a settlement engine which allows users to write options, exercise options, and redeem claims on assets, while handling fair assignment of exercises to claims written.

In order to perform option assignment, we slush options by day. Options written are put into a "bucket" of options, all written on the same day (defined as days offset from option type creation). Options writers claiming their exercise and underlying assets will retrieve the same ratio of exercised assets to unexercised as everyone else on that day.

When writing options, the writer is minted an equal number of ERC1155 fungible tokens corresponding to the amount of options written, as well as an NFT corresponding to a claim over that options lot. After option expiry, an options writer may claim their share of the underlying asset and exercise asset.

**What kind of bugs are you worried about?**
- Time
- Not being able to exercise before exerciseTimestamp or after expiryTimestamp, etc.
- Day-to-day boundaries, gaming this to get some advantage as either option writer or option holder
- Non-standard ERC20s affecting standard ERC20 assets custodied by the core contract
- Token ID encoding/decoding

**What parts of the project are most critical?**
-
- Safety of assets in the protocol
- Correctness and fairness of excercise/redeem logic, with fairness meaning that there is no gamability of who is exercised as a writer based on when and what amount they wrote, and that on exercise, everyone is able to get out the assets they should be after exercise/expiry.
- Correctness of fee/revenue logic

**What parts of the project are you worried about (where there could be lingering bugs)?**
-
- TokenURI generation is the least tested
- Anything time/boundary related
- Invariants that must hold, we haven't defined any yet

**Which areas would you like to focus on extra for higher assurance?**
-
- Fee Logic
- Time
- Asset custody and correctness

## Pre-Audit Checklist

- [x] Code is frozen
- [ ] Test coverage is 100%
- [x] 99% on OptionSettlementEngine.sol, [Line 554](https://github.com/valorem-labs-inc/valorem-core/blob/6c118f2090ba4f9ddac878a4afb1e5facb49b7ca/src/OptionSettlementEngine.sol#L554) has partial coverage, but both branches are exercised
- https://app.codecov.io/gh/valorem-labs-inc/valorem-core/blob/master/src/OptionSettlementEngine.sol - coverage report on core
- [x] Unit tests cover both positive and negative scenarios
- [x] All tests pass
- [x] Documentation provided
- [x] Code has Natspec comments
- [x] A README is provided on how to setup and run your test suite