Your Career, Onchain: Building a Resume Protocol with Purpose and Trust

In the traditional world, a resume is just a PDF. It is a claim, not a proof. Anyone can write "Expert in Solidity" on a document, and verifying that claim requires trust, phone calls, and manual friction.

As a smart contract engineer, I look at systems through the lens of reliability. I asked myself: Why is our professional reputation: one of our most valuable assets, stored on fragile, centralized servers?

I wanted to solve this by building the Resume Protocol: a decentralized registry for peer-to-peer professional endorsements.

This isn't just about putting data on a blockchain. It is about engineering a system where trust is cryptographic, ownership is absolute, and the design is thoughtful. Here is how I built it.

The Problem: Trust is Fragile
We currently rely on platforms like LinkedIn to host our professional identities. While useful, these platforms have structural weaknesses:

1. Fabrication: Claims are self-reported and often unverified.
2. Centralization: Your endorsements live on a company's database. If they change their API or ban your account, your reputation vanishes.
3. Lack of Ownership: You rent your profile; you do not own it.

My mission was to engineer a solution where reliability is baked into the code. I wanted a system that was Verifiable (traceable to a real address), Soulbound (non-transferable), and Consensual (you control what appears on your profile).

The Solution: Soulbound Tokens (SBTs)
To engineer this, I utilized Soulbound Tokens (SBTs).

In technical terms, this is a modified ERC-721 token. Unlike a standard NFT, which is designed to be traded or sold, an SBT is bound to an identity. Think of it like a university degree or a Nobel Prize, it belongs to you, and you cannot sell it to someone else.

Traditional Resume vs. Onchain Protocol

Feature	Traditional Resume	Resume Protocol (Onchain)
Source	Self-claimed	Peer-verified
Ownership	Hosted by platforms	Owned by YOU (Soulbound)
Trust	Hard to verify	Cryptographically verifiable
Transferability	N/A	Non-transferable (Identity-bound)

By deploying this on Base, we leverage the security of Ethereum with the accessibility required for a global onchain economy.

The Architecture of Trust
Excellence in engineering means choosing clarity over complexity. The protocol works on a simple but rigorous state machine.

The Analogy: Imagine a Digital Award Ceremony.

• The Issuer (your manager) decides to give you an award.
• The Protocol (the stage) checks if they are allowed to give awards right now (Rate Limiting).
• The Award (the Token) is presented to you.
• The Status: It starts as "Pending" until you walk up and accept it.

The "Consent" Pattern
One of the most deliberate design choices I made was the Consent Mechanism.

In many onchain systems, if someone sends you a token, it just appears in your wallet. For a professional resume, this is a vulnerability. You do not want spam or malicious endorsements clogging your reputation.

Therefore, the protocol enforces a two-step lifecycle:

1. Pending: An issuer sends an endorsement. It sits in a "limbo" state.
2. Active: You, the recipient, must explicitly sign a transaction to acceptEndorsement.

This puts the user in control. It is a small detail, but it reflects a thoughtful approach to user safety.

This diagram shows how a user interacts with the system to send an endorsement.

A Look at the Code

Let's look at the heart of the endorsement logic. I wrote this in Solidity using Foundry for rigorous testing.

Notice the specific checks. Every line represents a decision to prioritize security and reliability.

    /**
     * @notice Peer-to-Peer Endorsement with Anti-Spam checks.
     * @dev Enforces Rate Limits. Mints as PENDING (requires acceptance).
     */
    function endorsePeer(address to, string calldata skill, string calldata dataURI) external {
        // 1. Rate Limit Check
        if (block.timestamp < lastEndorsementTimestamp[msg.sender] + RATE_LIMIT_COOLDOWN) {
            revert RateLimitExceeded();
        }

        // 2. Mint as Pending
        _mintEndorsement(msg.sender, to, skill, dataURI, Status.Pending);

        // 3. Update Timestamp (Checks-Effects-Interactions)
        lastEndorsementTimestamp[msg.sender] = uint64(block.timestamp);
    }

Making it "Soulbound"

To ensure the token behaves as a reputation marker and not a financial asset, we override the transfer logic.

function _update(address to, uint256 tokenId, address auth) internal override returns (address) {
        address from = _ownerOf(tokenId);
        if (from != address(0) && to != address(0)) {
            revert SoulboundNonTransferable();
        }
        return super._update(to, tokenId, auth);
    }

Engineering Excellence: Testing

Smart contracts handle real value and in this case, real reputations. Therefore, "it works on my machine" is not enough.
I used Foundry to subject this protocol to extensive verification:

• Unit Tests: Verifying every state transition (Pending -> Active).
• Fuzz Testing: I threw thousands of random inputs at the contract to ensure it handles edge cases gracefully.
• Invariant Testing: Ensuring that no matter what happens, a user can never transfer their reputation token.

This rigor is what separates "code" from "engineering."

Building for the Future
I built the Resume Protocol because I believe the future of work is onchain. We are moving toward a world where your history, your skills, and your reputation are portable assets that you own.

This project is open-source. It is an invitation to collaborate. If you are a developer, a designer, or a builder who cares about clarity, purpose, and excellence, I invite you to review the code and contribute.

Repository: github.com/obinnafranklinduru/nft-resume-protocol

I am Obinna Duru, a Smart Contract Engineer dedicated to building reliable, secure, and efficient onchain systems.

Let's connect and build something you can trust..

• LinkedIn
• Twitter/X
• Portfolio

📚 Beginner's Glossary

• SBT (Soulbound Token): A non-transferable NFT. Once it's in your wallet, it's yours forever (unless revoked).
• Smart Contract: A digital program stored on the blockchain that runs automatically when specific conditions are met.
• Rate Limit: A security feature that prevents users from spamming the network by forcing them to wait between actions.
• Foundry: A blazing fast toolkit for Ethereum application development written in Rust.
• Onchain: Anything that lives directly on the blockchain.

"Smart contracts handle real value, so I build with reliability, thoughtfulness, and excellence."