Europeum

Dependency on External Registries and Bootstrap Logic: TrackAndTrace depends on out-of-scope IPolicyRegistry.checkPolicy for authoriseDid and migrationRemoveDocument, IDidRegistry.checkController for _authorize on DID_EBSI accounts, and ImplementationInitSelector plus Pagination from @ebsiint-sc/bootstrap for initialization and list queries. Core paths including _authorize, createDocument, grantAccess, revokeAccess, writeEvent, and authoriseDid treat live didRegistry and policiesRegistry addresses set in initialize (and policiesRegistry again in initializeV2) as authoritative. Misconfiguration, unavailability, or incorrect responses from those registries can halt legitimate operations or admit unauthorized document creation, access changes, or event writes.

Admin Control of Registry Addresses: Holders of DEFAULT_ADMIN_ROLE may call setPoliciesRegistry and setDidRegistry at any time, subject only to a non-zero address check. A substituted policy registry can redefine which addresses satisfy "TNT:authoriseDid". A substituted DID registry can redefine controller checks used by _authorize for creation, grants, revokes, and event writes across all documents.

Control Risks from Invited DID Whitelist: authoriseDid sets invitedDidEbsiAccounts after policiesRegistry.checkPolicy("TNT:authoriseDid", msg.sender) and _authorize of senderDid. _getAccountAccess grants SCOPE.TNT_CREATE from that mapping when documentHash is zero, which is the gate checked by both createDocument overloads. Holders of the "TNT:authoriseDid" policy therefore control which DID EBSI accounts may create documents, without on-chain bounds on how many accounts are whitelisted or how often the mapping is flipped. Blacklisting does not revoke existing documents, grants, or writeEvent rights.

Absence of Timelock Mechanisms for Critical Operations: Privilege-changing calls in TrackAndTrace take effect in the same transaction. No on-chain review window, cooling period, or multi-party approval gate exists inside this contract before those changes become enforceable.

Forced Execution Without Subject Consent: When ACCESS_ENUM.DELEGATE is revoked, _revokeAccess recursively revokes ACCESS_ENUM.WRITE for every account in the subject’s children array (bounded by MAX_DELEGATED_CHILDREN) without signatures from those children. Separately, a document creator’s controller may call removeDocument, which marks the document DocumentStatus.Deleted, clears subject index entries, and removes the hash from documentsMapped, ending Active access and further writes for all invitees without their consent while retaining nested storage as a permanent tombstone.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.

Upgrade Path Dependency: Initialization assumes a sequenced path where initialize sets DEFAULT_ADMIN_ROLE, policiesRegistry, and didRegistry, and initializeV2 uses reinitializer(2) only to replace policiesRegistry. didRegistry has no corresponding reinitializer. Incompatible storage layout changes relative to Document, Access_Struct, accessBySubject, and documentsMapped, or an incomplete upgrade sequence, can leave policy pointers or access indexes inconsistent with the new logic.

Unverified External Timestamp Proofs: Overloaded createDocument and writeEvent accept caller-supplied timestamp and timestampProof, persist them through _createDocument / _writeEvent with Source.External, and perform no on-chain validation of the proof against a signature, registry, or other verifier. Only timestamp != 0 and the usual DID-controller plus scope checks apply (plus a matured create commitment for document creation). Consumers that treat those fields as attested chronology may rely on values that TrackAndTrace does not cryptographically authenticate.

Unbounded Event Log Growth: _writeEvent appends to eventHashes without a per-document maximum count. String fields are capped at MAX_METADATA_LENGTH, but any account with WRITE access can still grow nested event storage indefinitely through many bounded writes. That growth increases gas costs for pagination over large event lists and leaves permanent storage on tombstoned documents.

Unbounded Invitee Iteration on Document Removal: removeDocument calls _detachDocumentSubjects, which iterates doc.allInvited with no upper bound. Subject count is otherwise uncapped by grantAccess (only DELEGATE children are limited by MAX_DELEGATED_CHILDREN). A document with a sufficiently large invitee list can push removeDocument past the block gas limit, preventing the creator from tombstoning the document and detaching subject indexes.

Ungated, Never-Cleared Create Commitments: commitCreateDocument accepts any non-zero commitment from any caller with no invite or role check, and writes permanently to createDocumentCommitments. Successful createDocument reveals validate maturity via _checkCreateDocumentCommitment but do not delete the commitment slot. Unused or spent commitments therefore accumulate indefinitely, enabling storage griefing by arbitrary accounts while invite eligibility is enforced only at reveal time.