# 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](https://docs.enzyme.finance/onyx-protocol/user-roles "mention"). 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](#hack "mention") 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