The Unseen security record

Line 133 of the `AuthenticatedProxy` contract is intended to control who can call the `proxy` function. The owner of the proxy can call the `proxy()` function which is intended. Additionally, if `revoked` is `false` (and it defaults to `false` when first deployed) AND the caller is authenticated in the `ProxyRegistry` contract, then the check also passes. In the `ProxyRegistry` contract, the owner can grant authentication to any address, which means that the owner of the `ProxyRegistry` contract can perform arbitrary function call / delegatecall of any user's proxy via an affiliated address. This is a critical risk, as the owner affiliated address can drain the asset of any user from its proxy, or destroy any user's proxy contract via a delegate call to `selfdestrct()` etc.

In the contract `BaseFeeCollector` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the withdraw address and set `_operator` address.  In the contract `BaseFeeCollector` the role `_operator` has authority over the functions `withdrawERC20Tokens()` and `withdraw()`. Any compromise to the `_operator` account may allow the hacker to take advantage of this authority and withdraw ERC20 and native token from the contract. In the contract `FeeCollector` the role `_operator` has authority over the function `unwrapAndWithdraw()`. Any compromise to the `_operator` account may allow the hacker to take advantage of this authority and unwrap token into its associated native token and withdraw it from the contract. In the contract `UnseenRegistry` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and grant authentication to an arbitrary non-zero address.  In the contract `ProxyRegistry` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and grant and revoke authentication on any non-zero address.  In the contract `AuthenticatedProxy` the role `_proxyowner` has authority over the functions `setRevoke()`, `transferProxyOwnership()`, and `proxy()`. Any compromise to the `_proxyowner` account may allow the hacker to take advantage of this authority and execute arbitrary external call and delegate call. In the contract `ExchangeCore` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change protocol fee and fee recipient.  In the contract `ContractMetadata` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change transfer validator address and `unseenMarketRegistry` address.  In the contract `ContractMetadata` the role `_owner` and `_CONFIGURER` have authority over the functions `setBaseURI()`, `setContractURI()`, `emitBatchMetadataUpdate()`, `setMaxSupply()`, `setProvenanceHash()`, and `setDefaultRoyalty()`. Any compromise to the `_owner` or `_CONFIGURER` account may allow the hacker to take advantage of this authority and change important project parameters such as the base URI and contract URI, token max supply and default royalties, etc. In the contract `UnseenToken` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and pause or unpause the contract, and change `tokenId` and add minter.  In the contract `UnseenToken` the role `MINTER` has authority over the functions shown in the diagram below. Any compromise to the `_role` account may allow the hacker to take advantage of this authority and mint tokens to arbitrary address.  In the contract `UnseenVesting` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and create vesting schedule.  In the contract `VestingLockup` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change NFT descriptor. ![](https://accelerator-tasks-prod.acc.corp.cert

All `_initialSupply` of the `UNCN` tokens are sent to the contract owner address. This is a centralization risk because the owner can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

In most commonly used proxy patterns (e.g. transparent proxy, UUPS, and diamond proxy), there is a clear separation of proxy and logic, in that all contract logic (with the possible exception of contract upgrade) are implemented in the logic contract, and the proxy contract delegate function calls via the `fallback()` function. However, for `TheGenerates`, the usage of proxy and logic are commingled. `TheGenerates` inherits `TGenContract` which contains a `fallback()` function that delegate calls to the `TheGeneratesConfigurer` contract. At the same time, all contracts in the inheritance chain, including `TheGenerates`, `TGenContract`, `ContractMetadata`, `MarketsPreapproved`, `TokenTransferValidator` etc. all contain function logic as well. Furthermore, within the `fallback()` function itself, some logic are delegated to the external `TheGeneratesConfigurer` contract, and some are redirected to functions implemented in the contract itself.

The code base contains interaction with third-party or out-of-scope contracts. For example, the `TokenTransferValidator` contract contains a setter function that sets the `_transferValidator` address, and the `ContractMetadata` contract utilizes the `_transferValidator` in the `_beforeTokenTransfers` hook. If the external `_transferValidator` contract fails to properly validate token transfers, then users' token transfer could be adversely impacted. Additionally, the `UnseenToken` contract interacts with third-party `interchainTokenService_` contract that is out of the scope of this audit. The scope of the audit treats third-party/out-of-scope entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets.