Delabs Adventure Pass Staking - Audit

The upper limit of the loop count is currently hard coded as 3443 in the `getOwnerStakedTokenIds()` and `getOwnerStakedTokenPositions()` functions. This means that all tokens must be traversed each time these functions are called, resulting in a long and costly process that may lead to potential out-of-gas failures. Additionally, it means that the total number of NFTs cannot be changed, even if the `totalSupply` of the NFTs changes.

In the `DelabsAdventurePassStaking` contract, users have the option to stake their `DelabsAdventurePass` NFTs for a locked period and withdraw them once the period is over. It appears that the only staking benefit is to increase the level, and we would like to confirm with the client the purpose of levels in the Delabs project. Additionally, we have observed that levels are being added when staking instead of when unstaking, implying that the level is already increased when a user chooses to stake for an extended period. Furthermore, the level will be retained with the NFT that is unstaked when the owner invokes the `forceBatchUnstake` function. Therefore, we would like to confirm with the client whether this aligns with the original design.

The contract serves as the underlying entity to interact with one unknown implementation, the `adventurePass`, which falls out of the scope of this audit. The scope of the audit treats the related entities as black boxes and assumes their functional correctness. However, in the real world, the unknown implementation can be compromised and this may lead to lost or stolen assets. In addition, upgrades of it can possibly create severe impacts, such as increasing fees of third parties, etc. ```solidity=40 IDelabsAdventurePass private adventurePass; ``` - The contract `DelabsAdventurePassStaking` interacts with the unknown contract with `IDelabsAdventurePass` interface via `adventurePass`.