Argus: Decentralized Certification

Argus is a project created during my M1 at INSA Lyon as part of the Cryptography & Decentralized Applications course.

For this project, we had to come up with an idea where smart contracts are genuinely useful, and—if possible—bring some innovation.

Our idea is simple: when you have an appointment with a surgeon, you trust that the hospital has ensured the surgeon is qualified—usually through a diploma. However, cases of forged or misrepresented diplomas have existed (surgeons, nurses, and other professionals lying on their CVs). Since the only reliable way to verify a diploma is often to contact the school, verification can be slow and can hinder recruiting. In the worst case, this can lead to a situation where a professional does not actually hold the required qualification.

You can find our implementation in the project repository.

Innovation

We looked at state-of-the-art solutions for this problem. While some blog posts discuss degree-verification tools, many results are either not publicly available or are hidden behind “contact us for pricing”, which makes it hard to compare and deploy solutions.

We also found GitHub repositories addressing the same topic using blockchain (as we planned). However, many of these solutions are flawed in a simple way: they do not follow the core idea of decentralization. They often rely on a centralized administrator (a person or company) that users must trust. Some also constrain degree creation to a single application, even though degree formats vary across schools and countries, and institutions may not want to be locked into one vendor’s tool.

Our goal is a fully decentralized approach where schools, recruiters, and students do not need to trust a single party—only the smart contract implementation. We also do not generate degree files; instead, we store meaningful, verifiable metadata. Rather than restricting creation, issuance, and verification to specific users, any participant can perform these actions within the protocol.

Proposed architecture

A fair question is: “What prevents me from creating a new wallet and issuing myself a degree from INSA Lyon?” That is exactly why we replace trust in a single administrator (for identity verification) with a mechanism based on aligned incentives.

Conceptually, we have three roles:

• Receiver (student): receives a certification
• Issuer (school): issues a certification
• Verifier (recruiter): verifies a certification

Each role has a clear incentive:

• A school wants its certifications to be verifiable, so it has an incentive to prove that its certifications are legitimate.
• A student wants certifications that can be verified, so they have an incentive to only accept legitimate certifications.
• A recruiter wants to assess candidates, so they have an incentive to verify certifications.

The verifier is the key actor: if a recruiter is malicious or does not care, no technical system can fully solve that problem.

Identity verification via school-owned endpoints

Since schools typically have official websites, we assume they can expose a standard endpoint such as /certification/identity. This JSON endpoint would list the Ethereum addresses used by the school to issue certificates, along with validity windows (start/end dates).

With only the school’s official domain (which can be found via any search engine), a student or recruiter can verify whether a certificate was issued by an address publicly declared by the institution.

There is a risk that a school’s servers could be compromised, but this risk is generally lower than relying on a single centralized platform that can go down or fail at verification.

Issuance workflow (proposal → acceptance → mint)

Because anyone can create a certification, we limit the risk of forcing a fake degree onto someone by requiring a proposal step:

1. The issuer creates a proposal containing the degree data encrypted with the student’s public key, along with a hash for integrity checks.
2. The student verifies the hash and checks the issuer’s identity (via the school endpoint), then accepts the proposal.
3. The accepted proposal is sent back to the school, which can then mint a soulbound NFT representing the degree. The NFT is automatically received by the student’s address.

To prevent speculation, the NFT is soulbound (non-transferable).

Verification workflow (recruiter)

To simplify verification, the frontend allows the student to generate a JSON file containing:

• the student’s address
• the decrypted data for their degrees

The student sends this file to the recruiter, who drops it into the dApp verification page. The dApp retrieves all NFTs owned by the address and matches them against the JSON entries by recomputing the hash from the decrypted data. The only manual step is providing the issuer’s domain (e.g., www.insa-lyon.fr) to check the school’s identity endpoint.

Limitations and improvements

This proof of concept could be simplified and could rely less on the frontend for web-based checks. One limitation of the current implementation is that it does not fully prove that an address really belongs to a given student (beyond control of the private key), but this can be improved with additional mechanisms.

Another improvement would be to reduce on-chain communication costs for proposals/acceptance. Using IPFS could also help schools attach supporting documents (e.g., a PDF version of the diploma) linked to the NFT.

If you are curious about the code, you can take a look at the repository.