Europeum

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

The EBSI Trusted Schemas Registry (TSR) is an on-chain component of the European Blockchain Services Infrastructure that stores, versions, and serves JSON schema definitions and their associated metadata for the EBSI ecosystem. Deployed as an upgradeable Solidity contract on an EBSI EVM-compatible ledger, it maintains an append-only history of schema revisions keyed by SHA2-256 content hashes, while delegating all write authorization to an external policy registry.

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

Documentation quality

• Functional requirements are not detailed.

• • Each external function in both files carries a short @dev one-liner describing what it does (e.g., "insertSchema enables to register new schema").

  • No in-scope documentation describes the roles model, despite authorization being delegated via the TSR:insertSchema/TSR:updateSchema/TSR:updateMetadata attribute checks.

  • Content-addressing (sha256\-derived IDs) and "latest revision" semantics in SchemaLib.sol are non-obvious design choices left undocumented.

  • Use cases, edge cases, and end-to-end flows between SchemaRegistry and SchemaLib are not described.

  • The @dev NatSpec provides a high-level functional picture, which lifts the score but stops at surface behavior.

• Technical description is not detailed.

• • Neither file documents validation rules, invariants, or upgrade/storage constraints (__gap, _version) as a technical specification.

  • NatSpec has no @param or @return tags on any function in either file.

  • Revert conditions and the pagination return tuple (items, total, howMany, prev, next) are undocumented.

  • The existing NatSpec covers the code at a surface level and is beneficial, but is insufficient to raise the technical score.

Code quality

• The code duplicates commonly known contracts instead of reusing them.

• The development environment is properly configured and runs locally with no external keys.

• Formatting, naming, and the upgradeable-contract hygiene in SchemaRegistry.sol (_disableInitializers(), initializer guard, reserved __gap) reflect solid engineering discipline.

Test coverage

Code coverage of the project is 99.07 % (statement coverage).

• Deployment and basic user interactions are covered with tests.

• Negative case coverage is present.

The system is composed of the SchemaRegistry contract and its supporting SchemaLib library, operating over a shared Schemas storage struct whose layout is declared in the out-of-scope ISchemaRegistry interface. SchemaRegistry is written as an upgradeable implementation intended for a beacon-style proxy deployment: it inherits OpenZeppelin Initializable, disables initializers in its constructor through _disableInitializers() (annotated with /// @custom:oz-upgrades-unsafe-allow constructor), exposes an initialize function guarded by the initializer modifier, and reserves a uint256[50] __gap for future storage additions. Introspection support for proxy tooling is provided through ImplementationInitSelector, whose getImplementationInitSelector is overridden to return the initialize selector.

Access control is not implemented locally but is delegated to an external IPolicyRegistry contract, whose address is fixed at initialization through the _tprAddress parameter and stored in policyRegistryContract. Every state-mutating entry point (insertSchema, updateSchema, updateMetadata) gates execution on a checkPolicy call carrying a TSR-scoped attribute string (for example "TSR:insertSchema") and the calling msg.sender, reverting when the caller lacks the required attribute. Read entry points are unrestricted and, where they return lists, are paginated: getSchemaIds, getSchemaRevisionIds, and getSchemaRevisionMetadataIds enforce page and page-size bounds (page size capped at 50) and compute slices through the Pagination library's paginate helper.

Business logic and all storage mutation are factored into SchemaLib, attached to the Schemas struct via using SchemaLib for Schemas, keeping the registry contract a thin authorization-and-pagination layer over the library. Schemas and metadata are content-addressed: revision identifiers and metadata identifiers are derived as SHA2-256 hashes of their respective byte payloads, with revision and metadata byte content stored once per hash in schemaRevisionStore and revisionMetadataStore, and ordered identifier lists tracked in schemaIdToRevisionIds and schemaIdRevisionIdToMetadataIds. The library emits SchemaInserted, SchemaUpdated, and MetadataUpdated events on each mutation and provides the corresponding read helpers consumed by the registry. Cross-contract dependencies comprise the external PolicyRegistry (via IPolicyRegistry) for authorization and shared bootstrap utilities (Pagination, ImplementationInitSelector) from the monorepo.

Files in Scope

• SchemaRegistry.sol — The upgradeable registry entry-point contract that initializes the external policy registry reference, enforces per-action authorization through checkPolicy, and exposes schema lifecycle operations (insertSchema, updateSchema, updateMetadata) alongside paginated and direct read functions (getSchemaIds, getLatestSchemaRevision, getSchemaRevisionIds, getSchemaRevision, getLatestSchemaRevisionMetadataByRevisionId, getSchemaRevisionMetadataIds, getSchemaRevisionMetadataByMetadataId), delegating storage logic to SchemaLib.

• SchemaLib.sol — A library operating on the Schemas storage struct that implements content-addressed schema and metadata storage using SHA2-256 hashing, handles registration and versioning through insertSchema, updateSchema, and updateMetadata, provides read helpers such as getLatestSchemaRevision, getSchemaRevision, getLatestSchemaRevisionMetadataByRevisionId, and getSchemaRevisionMetadataByMetadataId, and emits the SchemaInserted, SchemaUpdated, and MetadataUpdated events.

Privileged roles

SchemaRegistrysol

• Deployer / Initializer: Bootstraps the proxy by setting the policy registry dependency; gated by the initializer modifier so it can execute only once.

• • Can call initialize to set policyRegistryContract to the provided non-zero _tprAddress, thereby defining which external policy registry governs all subsequent access checks.

• TSR:insertSchema attribute holder: Entity that passes policyRegistryContract.checkPolicy("TSR:insertSchema", msg.sender).

• • Can call insertSchema to register a new schema together with its first revision and metadata.

• TSR:updateSchema attribute holder: Entity that passes policyRegistryContract.checkPolicy("TSR:updateSchema", msg.sender).

• • Can call updateSchema to append a new schema revision and associated metadata to an already-registered schema.

• TSR:updateMetadata attribute holder: Entity that passes policyRegistryContract.checkPolicy("TSR:updateMetadata", msg.sender).

• • Can call updateMetadata to append new metadata to an existing schema revision.

Note: all get* view functions (getSchemaIds, getLatestSchemaRevision, getSchemaRevisionIds, getSchemaRevision, getLatestSchemaRevisionMetadataByRevisionId, getSchemaRevisionMetadataIds, getSchemaRevisionMetadataByMetadataId) and getImplementationInitSelector are unrestricted and callable by any address.

SchemaLibsol

• No independently-enforced access control is present. The library functions are consumed via using SchemaLib for Schemas and operate on the caller contract's storage; the only guards are input/state validation require checks (non-empty inputs, registration existence), with all authorization enforced upstream by the policy gates in SchemaRegistry.sol.

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

Assets in Scope