Europeum

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

The in-scope contracts form the Policy Registry module of the EBSI (European Blockchain Services Infrastructure) on-chain identity and access stack, an EVM-based Solidity system. The registry stores named policy definitions and assigns them as attributes to user addresses, allowing other contracts to query whether a given user holds a given policy via checkPolicy.

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

Documentation quality

• Functional requirements are present, but only at a high level

• • PolicyRegistry function NatSpec @notice describes behavior, both scopes (global vs. per-target), and roles.

  • Access-control intent (onlyOperatorOrProxyOwner, checkPolicy fallback) explained inline.

  • No whitepaper, no functional-requirements doc.

  • No use cases, user flows, or interaction descriptions.

  • Subtle checkPolicy scope logic (target = msg.sender) not documented for integrators.

• Technical description is detailed.

• • Test suite present (policy, userattr, scoped-delegation specs) plus coverage script.

  • PolicyRegistry NatSpec has @param/@return and @dev validation rules.

  • No run instructions in README.

  • No standalone technical spec (architecture, deployment, storage layout).

Code quality

• Modern Solidity version 0.8.26 (not outdated).

• Correct OZ primitives, _disableInitializers(), __gap for upgrades.

• Consistent custom errors and events on all state changes.

• Dev environment configured (Hardhat 3, Solidity 0.8.26, optimizer, solhint, eslint).

• Runs locally, no external keys (default test mnemonic).

Test coverage

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

• Deployment and basic user interactions are covered with tests.

• Negative case coverage is missing.

The module centers on a single upgradeable contract, PolicyRegistry, deployed behind a versioned beacon proxy. It inherits AccessControlUpgradeable for role management, Initializable for proxy-based initialization, and ImplementationInitSelector from the external @ebsiint-sc/bootstrap package to expose the initializer selector consumed by the beacon deployment machinery. State is held in OpenZeppelin EnumerableMap and EnumerableSet structures: policy definitions are keyed by an incremental policyCount id and by a keccak256 hash of the policy name, while user assignments are tracked as composite-key sets over the tuple (user, targetContract, policyName).

Two conceptual entities are managed. Policy definitions are created and mutated by operators through insertPolicy, updatePolicy, activatePolicy, and deactivatePolicy, each policy carrying a name, a description, and an active status flag. User attribute assignments bind a user to one or more policy names within a scope: a scope of address(0) denotes an EBSI global policy, while a non-zero targetContract denotes a policy that applies only when that specific contract queries the registry. Assignments are created and removed through insertUserAttributes, insertScopedUserAttributes, deleteUserAttributes, and deleteScopedUserAttributes.

Access enforcement uses two scopes. Policy definition management and global attribute assignment are gated by OPERATOR_ROLE. Scoped attribute assignment is additionally permitted to the proxy owner of the target contract: the onlyOperatorOrProxyOwner modifier calls proxyOwner on the target through the IVersionedBeaconProxy interface and grants access when it returns the caller. The read path checkPolicy resolves a policy by id or name, then treats msg.sender as the target contract and returns true when the user holds the policy either for that specific target scope or for the global scope, giving global policies precedence-free fallback behavior. Read functions that enumerate policies, policy names, and users are paginated through the CustomPagination library, which wraps the external Pagination library from the bootstrap package and returns 1-based id slices with page metadata. The contract reserves a __gap storage slot array for upgrade-safe layout extension.

Files in Scope

• PolicyRegistry.sol — Upgradeable registry that defines, mutates, and queries named policies and binds them to users as global or per-target-contract attributes. Exposes operator-gated write functions for policy lifecycle and attribute assignment, an onlyOperatorOrProxyOwner path for scoped assignment, and paginated read functions including the checkPolicy authorization query used by other contracts.

• CustomPagination.sol — Library that paginates a range of incremental 1-based ids given a total count, page number, and page size. Delegates page-boundary math to the external Pagination.getPaginationParameters function and returns the id slice together with total, page-count, previous, and next metadata.

Privileged roles

PolicyRegistrysol

• DEFAULT_ADMIN_ROLE: Admin role for all roles in the contract; granted to the initializer caller. Can grant and revoke OPERATOR_ROLE and DEFAULT_ADMIN_ROLE via the inherited grantRole and revokeRole (inherited from AccessControlUpgradeable).

• OPERATOR_ROLE: Manages the policy catalog and global user attribute assignments; granted to the initializer caller.

• • Can call insertPolicy to create a new named policy definition.

  • Can call updatePolicy (by name or id) to change a policy description.

  • Can call activatePolicy and deactivatePolicy (by name or id) to toggle a policy's active status.

  • Can call insertUserAttributes and deleteUserAttributes to assign or remove global-scope policy attributes for a user.

  • Can call insertScopedUserAttributes and deleteScopedUserAttributes for any target contract (including address(0)).

• Target contract proxy owner: Any address returned by proxyOwner on a target contract that implements IVersionedBeaconProxy, as enforced by the onlyOperatorOrProxyOwner modifier.

• • Can call insertScopedUserAttributes and deleteScopedUserAttributes for the specific target contract it owns.

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

Assets in Scope