Europeum

We express our gratitude to the Europeum team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Europeum operates and scales Europe’s sovereign digital trust infrastructure, enabling secure, transparent, and interoperable services across the public and private sectors.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

• The contracts contain NatSpec documentation explaining the versioning, ownership, registration, and opt-in upgrade model.

• However, the package README describes an outdated proxy architecture and does not accurately reflect the current implementation, where version and ownership data are stored in the beacon.

Code quality

• The code is concise and generally follows established Solidity conventions.

• The development environment is configured, and custom errors are used consistently.

Test coverage

Code coverage of the project is 100% (branch coverage).

• Deployment, initialization, version publication, proxy upgrades, deprecation, ownership transfers, access control, and multiple-user interactions are covered.

Beacon Proxy is an upgrade pattern composed of the following contracts:

VersionedUpgradeableBeacon — an Ownable beacon that stores multiple implementation versions and, per proxy, the version that proxy is pinned to and the owner allowed to opt it into a new version. It has the following attributes:

• Initial version: 1, set at deployment from initialImplementation.

• A version can be marked deprecated via deprecateVersion(version). This blocks opt-in upgrades through upgradeProxyToVersion and, if the deprecated version is the current latest, also blocks new proxy registration through registerProxy. Proxies already pinned to that version continue to resolve to it.

• Any caller that hasn't pinned a version (version 0) resolves to the current latest version — this makes a plain OpenZeppelin BeaconProxy pointed at this beacon behave exactly like it would against a standard UpgradeableBeacon.

• The beacon falls back to the latest implementation for any unregistered proxy so that a plain OpenZeppelin BeaconProxy pointed at it behaves exactly like a normal OZ upgradeable beacon, and this is considered acceptable because the network is permissioned — write access is gated behind DID registration, trusted-issuer authorization, or policy/governor checks at the API layer

VersionedBeaconProxy — an OpenZeppelin BeaconProxy that registers itself with the beacon at construction via registerProxy(owner_), pinning its resolved version and recording its owner on the beacon. It has the following attributes:

• Version and ownership state live entirely on the beacon, keyed by the proxy's own address, not on the proxy itself.

• Its beacon address is set once, immutably, at deployment and can never be changed afterward.

Privileged roles

• The owner of the VersionedUpgradeableBeacon contract can publish new implementation versions (addVersion) and mark any version as deprecated (deprecateVersion). It cannot force any already-deployed proxy to change which implementation it resolves to — a proxy only moves to a different version when that proxy's own registered owner explicitly calls upgradeProxyToVersion. The beacon owner therefore does not have unilateral control over live proxies, only over which versions exist and are offered.

• The owner of a given proxy (set once via registerProxy at deployment, transferable via transferProxyOwnership) can opt that specific proxy into any available, non-deprecated version via upgradeProxyToVersion, and can transfer that ownership to another account. This owner has no authority over the beacon's set of versions or over any other proxy registered to it — their control is scoped strictly to their own proxy.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope