Add Optional Strict Monotonic Timestamp and Anti-Backdate Checks

[Oluwaseyi89]

Summary

Update the registry_contract to optionally enforce that new document/project entries have strictly increasing (monotonic) timestamps and cannot be backdated, ensuring historical integrity and preventing manipulation of project/document history.

Social Media Link

Let's collaborate on Discord. And ensure to star our repo.

Technical Context

• Motivation: Allowing backdated or non-monotonic timestamps can undermine the trustworthiness of the registry, enabling actors to rewrite history or create ambiguous document orderings. Enforcing monotonicity and anti-backdating protects the integrity of the registry timeline.
• Current State: The contract does not enforce any ordering or anti-backdating checks on timestamps for new entries.

Requirements

Contract Changes

• Add an optional (configurable) flag to enable strict monotonic timestamp enforcement.
• When enabled, require that each new document/project entry has a timestamp strictly greater than the previous entry for the same project.
• Reject any entry with a timestamp less than or equal to the last recorded timestamp (anti-backdate).
• Return clear error messages for violations.

Acceptance Criteria

• When enabled, contract enforces strict monotonicity and anti-backdating for timestamps.
• Violations are rejected with clear errors.
• Unit tests cover:
  • Successful addition of monotonic entries
  • Rejection of backdated or duplicate-timestamp entries
  • Toggle of the enforcement flag

Definition of Done

• PR with contract code changes and tests
• Documentation updated to describe the enforcement option
• Team review completed

Working Directory:

stellar-core/verifiable-registry/contracts/registry_contract

---

[BashMan11]

@BashMan11 has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

I will like to take on this issue.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @BashMan11 to this issue.

[drips-wave]

Congratulations, @BashMan11! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

🧑‍💻 @BashMan11: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[BashMan11]

Resolved in PR #367 (branch fix/issues-313-314-316-318).

[BashMan11]

Implemented in PR #367. This issue will be closed when the PR is merged.

[drips-wave]

This issue has been completed by @BashMan11 as part of the Stellar Wave Program's 5th Wave 🥳

😎 @BashMan11: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.