API3Market

The subscription queues have a maximum size of 5 subscriptions. As long as the new subscription is equal to or better than at least one subscription in the queue, it will added. If it is equal, it must have an `endTimestamp` further in the future. However, if the queue is full and someone wants to queue a subscription that is better than all of them but has a lower `endTimestamp`, that subscription will fail to be added with error "Subscription queue full". Therefore, an attacker could fill the queue with the lowest-quality subscriptions and prevent better subscriptions from being added. However, this requires that more unique update parameters exist in the Merkle tree for a given dAPI name than the maximum allowed in the queue. The API3 team has confirmed that more than five possible update parameter configurations should not exist in the Merkle tree. Since the number of approved update parameter configurations, however, cannot be verified on-chain, this issue remains possible.

The smart contracts in scope rely on the correct off-chain construction of Merkle trees. The following constraints are not enforced on-chain upon Merkle root submission and, if ever accidentally or intentionally violated, could lead to security issues and/or inconsistencies: 1. The Management Merkle Tree cannot contain a specific dAPI name more than once. Otherwise, anyone can change the pointer of the dAPI name to the data feed ID. 2. A dAPI name in the management Merkle tree should not be re-pointed to a different data feed during an active subscription. This might violate the purchasing conditions of the subscriber. 3. All entries of the same dAPI name in the management Merkle tree must point to the same sponsor wallet.

Purchasing a subscription will result in a payment to sponsor wallets that can be quite substantial (> 5 ETH). These funds should be used by Airseekers to pay for the gas fees of updates. However, the owner of the sponsor wallet needs to be trusted not to mistreat the funds. The only incentive that keeps them from draining those funds is reputation. Furthermore, compromised sponsor wallets will also prevent the continued operation of already purchased subscriptions unless the API3 team provides funds.

The Merkle roots of management Merkle trees can be replayed across all chains. This is intended to reduce the signing overhead. However, if all chains are not synchronized in terms of data feed IDs, this could potentially result in invalid Merkle trees being activated and, consequently, incorrect data feed IDs being activated or transactions reverting because the data feed ID is not registered anymore. Furthermore, identical data feed IDs must be used across all chains.

The owner of the contracts can call `transferOwnership()` to transfer the ownership to a new address. If an uncontrollable address is accidentally provided as the new owner address then the contract will no longer have an active owner, and functions with the `onlyOwner` modifier can no longer be executed. This is only relevant if `HashRegistry.sol` is used as a standalone contract since ownership transfer is disallowed in `API3Market`.

Users can deposit more funds than necessary to purchase subscriptions through `buySubscription()`. Although the API3 Front-end likely mitigates this, it should not be possible for a user to deposit exceptionally more than needed when buying a subscription. Particularly, if the sponsor wallet already has (almost) sufficient funds to cover subscriptions, the function shouldn't accept these excess funds.

In several instances, the `API3Market` contract calls functions in the `API3ServerV1 ` contract. However, the target contract is out of scope for this audit. While we checked the interdependencies, we trust that the `API3ServerV1` correctly handles all function calls. Particularly, we trust that necessary checks for external functions in `API3Market` are made in `API3ServerV1` to prevent unauthorized state changes, such as `Api3Market.updateBeaconWithSignedData()`.

In `HashRegistry`, the owner can specify which signers are required to set the hash for a specific hash type. However, the owner can also set the hash for any hash type. This leads to a situation in which the owner's address has a disproportionate control when compared to the signers. For example, consider a scenario where the owner's address operates under a 4-of-8 multisig scheme, and there exists a specific hash type that requires authorization from 4 signers. In this case, the 4-of-8 multisig configuration is, in essence, less secure compared to a setup that directly uses a 4-of-4 multisig structure, which would be entirely made up of these signers. Additionally, the separation of roles may be violated in a case where the addresses responsible for updating a specific hash type are overruled by the owner address. Of course, the owner can also set the signers, so it needs to be the most secure.

If the `owner`renounces their ownership, all ownable contracts will be left without an owner. Consequently, any function guarded by the `onlyOwner` modifier will no longer be able to be executed. This is only relevant in case `HashRegistry.sol` is used as a standalone contract.

The following are the smart contracts and their associated roles. Many of the smart contracts contain roles that are necessary for the correct operation of the system. Therefore, roles, such as the default admin role, should be held by a multi-sig wallet. 1. `Api3Market` 1. Has an `owner` but all privileged functions exist in the inherited `HashRegistry`. 2. `HashRegistry` 1. Is inherited by `Api3Market` and shares an `owner`. 2. The `owner` can set signers for specific hash types including removing or adding signers. 3. The `owner` can set hashes for hash types, including overriding hashes set by the signers. 4. The signers can use m-of-m signatures to set the hash for a hash type they are allowed to set. 5. The signers can also delegate their signature to any address including addresses that do not have an associated private key. This will effectively prevent the hash from being changed until the delegation expires or the owner removes them. This is equivalent to a signer choosing not to sign. 3. `AirseekerRegistry` 1. All of its state-changing functions can only be called by the owner except for `registerDataFeed()`. 2. It may be owned by `Api3Market` or exist as a standalone smart contract with a different owner. The `owner` privileges on `HashRegistry.sol`implies the following rights: 1. The `owner` can change the data feed ID(s) the dAPI name points to. 2. The sponsor wallet that will receive funds for a (dAPI name, data feed ID) tuple. 3. The accepted `updateParameters`, `duration`, and `price` of a dAPI name.