Vulnerability: zBanc - inconsistent DynamicContractRegistry, admin risks
Severity: medium

Description:
`DynamicContractRegistry` is a wrapper registry that allows the zBanc to use the custom upgrader contract while still providing access to the normal bancor registry.\\nFor this to work, the registry owner can add or override any registry setting. Settings that don't exist in this contract are attempted to be retrieved from an underlying registry (contractRegistry).\\n```\\nfunction registerAddress(bytes32 \\_contractName, address \\_contractAddress)\\n    public\\n    ownerOnly\\n    validAddress(\\_contractAddress)\\n{\\n```\\n\\nIf the item does not exist in the registry, the request is forwarded to the underlying registry.\\n```\\nfunction addressOf(bytes32 \\_contractName) public view override returns (address) {\\n    if(items[\\_contractName].contractAddress != address(0)){\\n      return items[\\_contractName].contractAddress;\\n    }else{\\n      return contractRegistry.addressOf(\\_contractName);\\n    }\\n}\\n```\\n\\nAccording to the documentation this registry is owned by zer0 admins and this means users have to trust zer0 admins to play fair.\\nTo handle this, we deploy our own ConverterUpgrader and ContractRegistry owned by zer0 admins who can register new addresses\\nThe owner of the registry (zer0 admins) can change the underlying registry contract at will. The owner can also add new or override any settings that already exist in the underlying registry. This may for example allow a malicious owner to change the upgrader contract in an attempt to potentially steal funds from a token converter or upgrade to a new malicious contract. The owner can also front-run registry calls changing registry settings and thus influencing the outcome. Such an event will not go unnoticed as events are emitted.\\nIt should also be noted that `itemCount` will return only the number of items in the wrapper registry but not the number of items in the underlying registry. This may have an unpredictable effect on components consuming this information.\\n```\\n/\\*\\*\\n \\* @dev returns the number of items in the registry\\n \\*\\n \\* @return number of items\\n\\*/\\nfunction itemCount() public view returns (uint256) {\\n    return contractNames.length;\\n}\\n```\\n

Impact:

Recommended mitigation:
Resolution\\nThe client acknowledged the admin risk and addressed the `itemCount` concerns by exposing another method that only returns the overridden entries. The following statement was provided:\\n5.10 - keeping this pattern which matches the bancor pattern, and noting the DCR should be owned by a DAO, which is our plan. solved itemCount issue - Added dcrItemCount and made itemCount call the bancor registry's itemCount, so unpredictable behavior due to the count should be eliminated.\\nRequire the owner/zer0 admins to be a DAO or multisig and enforce 2-step (notify->wait->upgrade) registry updates (e.g. by requiring voting or timelocks in the admin contract). Provide transparency about who is the owner of the registry as this may not be clear for everyone. Evaluate the impact of `itemCount` only returning the number of settings in the wrapper not taking into account entries in the subcontract (including pot. overlaps).