Risks and Limitations

This is not an exhaustive list, but details key risks (with possible mitigations) and limitations of core architecture.

Hack

core mitigation: the only assets that Onyx has access to are the assets held inside its contracts: pending async deposits, unclaimed provisioned fees, unexecuted provisioned redemptions. Asset management wallets are never directly pulled from (assets must always be externally transferred into Shares for use). This creates a full partition between Onyx and any number of asset management wallets themselves, leaving no opportunity attackers to steal from non-pending holdings.

Trusted Roles

risk:owner and admin are fully-trusted

See User roles. They can, e.g.,

• inflate/deflate shares supply

• set arbitrary share prices

• withdraw all ERC20 tokens held in Shares

user mitigation example: instead of an EOA admin, use a smart contract that limits allowed calls

core mitigation: see #Hack mitigation

System

risk: tiny shares supply (e.g., donation attacks)

Rather than apply a core mitigating pattern, this is left to individual Onyx instances.

user mitigation example: an admin can mint "existential shares" to an unaccessible address

user mitigation example: an admin must not execute deposit/redeem requests for tiny shares amounts

limitation: irregular ERC20 token behaviors

Contracts are not intended to handle irregular token behaviors such as:

• fee-on-transfer

• rebasing

• re-enterable callbacks