[Certificate] Revocation Registry

[ayomideadeniran]

Description

Implement a system for the institution to revoke certificates if academic dishonesty is found.

Requirements

• Add a revoked flag to the Certificate struct or a separate revocation map.
• Implement revoke(symbol: Symbol) restricted to ADMIN.
• Update get_certificate to reflect revocation status.

Level

• Intermediate

Rules for Contributors

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

[1sraeliteX]

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

I would like to work on this issue because certificate integrity depends on a reliable revocation mechanism, and without one, dishonesty findings have no enforceable on-chain consequence. I'll add the revoked flag to the Certificate struct or a dedicated revocation map, implement revoke(symbol: Symbol) restricted to ADMIN, and update get_certificate to reflect revocation status.
ETA: 2 days.
Thanks!

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

[PatrickKish1]

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

Real-world credential systems need revocation (compromise, fraud, policy change). A minimal “revoked flag” on a cert is not enough if verifiers cannot query whether a given credential id is still trustworthy in O(1) or bounded gas. The issue likely expects a registry or bitmap-style approach plus events so off-chain indexers can mirror state.

Define who may revoke (issuer only, council, etc.) and enforce with require_auth / stored roles consistent with the repo.

Persist revocation entries without breaking existing reads; ensure double-revoke is idempotent or returns a clear error, per spec.

Emit a typed event (certificate id, revoker, optional reason) for transparency.

Tests: revoke happy path, unauthorized revoke, verify query returns false for revoked id, and migration-safe behavior if old certs predate the feature.

Same contract fundamentals as RBAC and upgrade-aware storage: authorized mutation + auditable events + 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.