Europeum

Contracts calling deployProxy() become the proxy’s beacon-level upgrade owner and must implement properly authorized functions to call upgradeProxyToVersion() and transferProxyOwnership() on the beacon; otherwise, the proxy’s upgrade and ownership-transfer rights will be inaccessible.

Because EBSI_GOVERNOR bypasses didRegistry.checkController, it can deploy a proxy using any supplied DID without proving control, after which the factory stores, indexes, and emits that DID as the proxy’s deployment attribution.

EBSI_GOVERNOR can immediately replace the factory’s DID and policy registries with any non-zero address, potentially changing authorization behavior or preventing legitimate deployments if the role is compromised.

ProxyFactory and ProxyTemplateRegistry are deployed behind upgradeable beacon proxies, allowing the relevant beacon owner to replace their logic for all instances; if this authority is compromised or misused, authorization rules, template records, and deployment behavior could be changed without protection from any timelock or approval mechanism in the scoped contracts.

Because deprecation only blocks one template name and version, the same beacon can be registered again with a different name or version and used for new proxy deployments.

Implementation initializers execute with msg.sender set to the factory, in both deployment paths — via delegatecall from the proxy in deployProxy and via functionCall in deployProxyWithSalt. Any implementation that derives privileges from msg.sender inside initialize (granting an admin role, setting an owner) will assign them to ProxyFactory rather than to the deployer. Privileged addresses must be passed explicitly in initData.

Pagination helpers used by getDeployedContracts and getContractsByTemplate can return prev = 0 for an empty list when page >= 2, and a very large out-of-range page can overflow the cursor calculation and revert with panic 0x11 instead of returning an empty page.

A registered proxy can deploy with an empty deployerDID and reuse its parent’s stored DID without a new didRegistry.checkController check. If that DID’s controller is later revoked or the parent proxy is compromised, the factory still allows further deployments under the old DID until an EBSI_GOVERNOR calls setDeploymentActive. Until then, unauthorized or obsolete callers can keep creating proxies attributed to a DID they no longer control. The team stated that this is intentional.

functionCall is a call from the factory into the proxy. Any implementation that treats msg.sender as owner/admin during initialize assigns that role to ProxyFactory, not the deployer. Privileged addresses must come from initData / the separate owner arg.

Every factory deployment creates a VersionedBeaconProxy, which calls registerProxy on template.beaconAddress in its constructor. addTemplate only checks standard IBeacon.implementation(), so a plain OpenZeppelin UpgradeableBeacon can be registered even though it has no registerProxy. Any later deployProxy / deployProxyWithSalt for that template then reverts in the proxy constructor, so the template appears active but no proxy can be deployed from it. Therefore, Normal OZ UpgradeableBeacon is not supported in this code.