Documentation

Passey Options lets you create simple physical options on HyperEVM: get paid upfront to buy low or sell high, with collateral held onchain until expiry.

Intro

Passey uses physical options. A buy low position is a secured put: you commit to buy the asset at a chosen price and receive premium upfront. A sell high position is a covered call: you commit to sell the asset at a chosen price and receive premium upfront.

The app is designed for users who want to earn yield, set target entry prices, or set target exit prices without relying on an offchain custodian.

How it works

Orders are signed offchain and filled onchain. When an order is filled, the option book creates a new option contract for that specific trade, transfers the seller's collateral into it, pays the premium to the seller, and mints position NFTs for the buyer and seller.

Choose the market, side, strike, expiry, size, and premium.
The seller posts collateral: base token for calls, quote token for puts.
The buyer can exercise during the exercise window after expiry.
If the option is not exercised, the collateral is withdrawn back to the seller.

Deposit from Hyperliquid to HyperEVM

Open Hyperliquid and go to Portfolio or your account overview.
Use Core → EVM to bridge from Hyperliquid Core to the HyperEVM chain your wallet uses for this app.
Choose the asset, enter an amount, and confirm the deposit / bridge flow.
Keep native HYPE on HyperEVM for gas. Sending only USDC or other ERC-20s without HYPE will leave you unable to pay transaction fees.

Hyperliquid: Portfolio and Core to EVM path — Portfolio and bridge entry (Core → EVM).

Hyperliquid: EVM deposit flow — Deposit / bridge step.

Hyperliquid: confirm deposit — Confirm and track the transfer.

Solidity audit report

Preamble

The option implementation can be changed by the option book owner, but this only impacts newly created options. Existing options cannot be changed by that future setting. Option withdrawals can also be triggered by anyone after expiry and the exercise window, but funds are sent to their proper owner rather than to msg.sender. This lets third parties, including Passey, clean up expired options and pay gas for users.

Users are advised to check the contracts implementation on hyperevmscan and run their own browser LLM to review them.

Scope

packages/foundry/contracts/PhysicalOption.sol
packages/foundry/contracts/PhysicalOptionBook.sol
packages/foundry/test/PhysicalOption.t.sol
packages/foundry/test/PhysicalOptionBook.t.sol

Deployed option book: 0xE5704595828E560eA3c5ea6FE2EbD847e3BcB512

Current option implementation: 0xffE6163cD653F1edef381322a6EC681A7b72A696

Executive summary

No critical or high-severity issues were identified in this focused review of the option creation, exercise, withdrawal, and order-fill flows. The most important user-facing caveat is that the ERC-721 position NFTs are tracking receipts, while the actual exercise and withdrawal permissions are bound to the stored buyer and seller addresses inside each option contract.

The main trust assumption is operational: the option book owner chooses the implementation used for new options. This does not mutate existing options, but users should still review new implementation addresses before trading after an implementation change.

Architecture reviewed

PhysicalOptionBook verifies signed EIP-712 orders, tracks partial fills by order hash, transfers premium from buyer to seller, escrows seller collateral, creates a new option clone, and mints buyer and seller position NFTs. PhysicalOption stores the buyer, seller, token pair, amount, strike, expiry, premium, option type, and lifecycle flags for one specific option.

Findings

Medium

Option implementation can be changed for future options only

Impact: The option book owner can update the implementation address used when creating new options. Existing options are not controlled by that future setting, so a later implementation change does not rewrite already-created positions.

Evidence: PhysicalOptionBook.changeImplementation is owner-only and Clones.clone uses the implementation address at option creation time.

Recommendation: Treat implementation changes as governance events. Announce them clearly and encourage users to verify the implementation address before filling new orders.

Medium

Position NFTs do not carry exercise or withdrawal authority

Impact: The option book mints NFTs to buyer and seller for tracking, but PhysicalOption.exercise checks the stored buyer and withdraw sends funds to the stored seller. If a position NFT is transferred, the economic rights in the option contract do not automatically transfer with it.

Evidence: PhysicalOption stores buyer and seller during initialize; exercise requires msg.sender == buyer, and withdraw pays seller.

Recommendation: Avoid presenting these NFTs as transferable claims unless the contract model is changed to resolve buyer and seller rights from NFT ownership.

Low

Token and decimal assumptions are pushed to order creators

Impact: Orders can reference arbitrary ERC-20 tokens. Collateral and premium calculations rely on base token decimals and standard ERC-20 transfer behavior. Non-standard, fee-on-transfer, rebasing, or malicious tokens can create unexpected accounting or execution behavior.

Evidence: PhysicalOptionBook.getCollateralAmount and premium calculation use IERC20Metadata(baseToken).decimals; token transfers use SafeERC20 but there is no token allowlist in the reviewed contracts.

Recommendation: Restrict the UI and published markets to vetted tokens, and consider an onchain allowlist if permissionless token support is not an explicit goal.

Low

One-hour exercise window creates liveness risk

Impact: Buyers must exercise after expiry and before expiry plus EXERCISE_WINDOW. If the buyer is unavailable, lacks gas, lacks allowance, or the network is congested, the seller can withdraw collateral after the window.

Evidence: PhysicalOption.EXERCISE_WINDOW is fixed at 3600 seconds, and canExercise is false once that window has passed.

Recommendation: Make the exercise window visible before trade confirmation and in position screens. Consider longer windows if the product targets less active users.

Informational

Expired option withdrawal is permissionless by design

Impact: After expiry plus the exercise window, anyone can call withdraw. The collateral is sent to the stored seller address, not msg.sender, so third parties can clean up expired positions and pay gas without taking funds.

Evidence: PhysicalOption.withdraw transfers the remaining collateral token balance to seller and sets withdrawn before the transfer.

Recommendation: Keep this behavior documented for users because it may look unusual in block explorers even though funds route to the rightful owner.

Positive security checks

Initialization rejects zero buyer, zero seller, zero token addresses, zero amount, zero strike, expired options, and zero premium.
Options cannot be initialized twice.
Only the stored buyer can exercise an option.
Exercise is only available after expiry and before the exercise window closes.
Exercise and withdrawal are mutually exclusive through exercised and withdrawn state flags.
Put exercise transfers base from buyer to seller and quote collateral from the option to buyer.
Call exercise transfers quote from buyer to seller and base collateral from the option to buyer.
Order signatures are verified with EIP-712 before fills.
Order fill amounts are tracked by order hash and cannot exceed maxMakerTotalAmount.
The option book mints two tracking NFTs per created option and maps both token IDs to the option clone.

Test coverage reviewed

The Foundry tests cover put and call initialization, invalid initialization inputs, double initialization protection, buyer-only exercise, exercise timing, successful put and call settlement, double exercise prevention, withdrawal timing, double withdrawal prevention, clone initialization, owner-only implementation changes, invalid implementation rejection, signed order verification, order expiry, premium floor checks, max fill enforcement, option creation, and NFT creation.

Residual risk and limitations

This report is a source-level review of the listed contracts and tests, not a formal audit. It does not include fuzzing, invariant testing, mainnet transaction monitoring, economic stress testing, oracle analysis, or a review of offchain orderbook infrastructure. Users should verify deployed bytecode and source on Hyperevmscan and may ask their own browser LLM to review the same contracts.