[Certificate] Certificate Expiration & Renewal Logic

[ayomideadeniran]

Description

Add an expiration date to certificates (e.g., valid for 1 year) and a mechanism for students to "renew" them upon re-assessment.

Requirements

• Update Certificate struct with expiry_date: u64.
• Add is_valid(symbol: Symbol) helper.
• Implement renew_certificate function with authorization.

Level

• Intermediate

Rules for Contributors

• Please add an ETA (no more than 2 days) when expressing interest.

[whitezaddy]

@whitezaddy has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Hi, I'd like to work on this issue!

Hello there, I'd love to work on this issue because I am very conversant with solving problems like this!

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

[jadonamite]

@jadonamite has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Hi maintainer can I work on this

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

[PatrickKish1]

@PatrickKish1 has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Why the work matters
Certificates without explicit expiry and renewal rules become impossible to reason about for verifiers: an old credential might still look “valid” on-chain while the issuer intended it to lapse, or renewals might double-mint if not modeled carefully. This issue asks for time-based lifecycle logic on top of whatever certificate storage and minting paths already exist, which is exactly the kind of change that must be test-heavy (edge dates, renewal after expiry, no duplicate active certs if the spec forbids it).

Read the existing certificate type and issuance flow; add fields or a companion structure for valid_until, renewal window, and possibly a renewed_from / generation counter if the issue specifies it.
Implement renewal as a distinct authorized path (issuer or holder, per spec) that updates state atomically and emits an event indexers can follow.

Add Soroban tests: first issuance, expiry boundary (ledger timestamp), successful renewal, rejected renewal when not allowed, and any overflow-safe arithmetic for timestamps.
Update any student-facing or internal docs so future labs do not bypass the new rules.

I have already worked on Stellar/Soroban contracts with persistent storage, auth checks, and events (for example StellarGrant-style admin-gated operations). Expiration and renewal is the same skill set: state machine + explicit errors + tests.

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

[Ndanusa]

@Ndanusa has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Can I work on this issue ?

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