A decentralized professional credential verification platform built on Stellar Soroban smart contracts, using Federated Byzantine Agreement (FBA) trust slices to audit engineering licenses and degrees across borders.

Engineering certifications vary by country, making it difficult for international firms to verify credentials quickly and reliably. QuorumProof replaces fragmented government portals with a trustless, privacy-preserving audit layer — powered by the same consensus model that underlies Stellar itself.

QuorumProof lets engineers build a Quorum Slice — a personal trust network made up of:

• 🎓 Their University (degree attestation)
• 🏛️ A National Engineering Society (license validation)
• 🏢 Previous Employers (professional history)

Each node in the slice co-signs a Soulbound Token (SBT) on Stellar, creating a tamper-proof, portable credential that any firm can verify instantly — without contacting each institution individually.

This applies the Stellar whitepaper's "individual trust decisions" model to a high-stakes professional use case.

Real BLS12-381 pairing-based Groth16 and PLONK verification is implemented in verify_groth16_proof and verify_plonk_proof (see groth16.rs and plonk.rs).

verify_claim and related legacy functions are test-only. They are compiled exclusively behind #[cfg(any(test, feature = "testutils"))] and are not exported to the production WASM binary. Do not rely on them in integration code.

verify_bulletproof_range is a fail-closed stub (always returns false) until a genuine Bulletproofs inner-product argument over BLS12-381 is integrated. The previous SHA-256 hash heuristic had no cryptographic binding to the committed value and has been removed. Tracked in #1415.

encrypt_metadata / decrypt_metadata have been replaced with panicking stubs. On-chain encryption is not the correct design for Soroban — ledger state is publicly visible regardless of any flag. Callers must encrypt off-chain before storing metadata. Tracked in #1416.

compress_metadata / decompress_metadata have been replaced with panicking stubs. The previous implementation only toggled a flag with no effect on stored byte length. Callers must compress off-chain before storing metadata. Tracked in #1417.

create_disclosure_proof / verify_disclosure are bound but not private. They provide an on-chain commitment binding a proof to the exact (credential_id, fields_to_reveal) pair it was created for, rejecting any proof that doesn't match — but fields_to_reveal is not hidden from the chain and no zero-knowledge property is provided. Real selective-disclosure ZK proofs are tracked alongside the items above.

• Audit Slices: Define your own quorum of trusted attestors (university, licensing body, employers)
• Soulbound Tokens (SBTs): Non-transferable on-chain credentials tied to your Stellar identity
• Conditional Verification: Claim-specific proof verification is implemented via the zk_verifier contract, with design details and caveats documented in docs/zk-verification-implementation.md
• Cross-Border Ready: Instant verification for international hiring, no embassy letters or notarizations
• Privacy-First: Credential holders control what is revealed and to whom
• Trustless: No central registry — verification is enforced by smart contract logic

• Rust (1.70+)
• Soroban CLI
• Stellar CLI

./scripts/build.sh

./scripts/test.sh

Copy the example environment file:

cp .env.example .env

Configure your environment variables in .env:

# Network configuration
STELLAR_NETWORK=testnet
STELLAR_RPC_URL=https://soroban-testnet.stellar.org

# Contract addresses (after deployment)
CONTRACT_QUORUM_PROOF=<your-contract-id>
CONTRACT_SBT_REGISTRY=<your-contract-id>
CONTRACT_ZK_VERIFIER=<your-contract-id>
# contracts/bbs_plus_v1 (BBS+ selective-disclosure crypto core) is a Rust
# library crate that other contract crates link in — not a standalone
# deployed contract — so there is no address to set. It appears as an
# in-scope component in SECURITY.md because it is cryptographic code in this
# repo, not because it is separately deployed.
# CONTRACT_BBS_PLUS_V1=

# Frontend configuration
VITE_STELLAR_NETWORK=testnet
VITE_STELLAR_RPC_URL=https://soroban-testnet.stellar.org

Network configurations are defined in environments.toml:

• testnet — Stellar testnet
• mainnet — Stellar mainnet
• futurenet — Stellar futurenet
• standalone — Local development

# Configure your testnet identity first
stellar keys generate deployer --network testnet

# Deploy
./scripts/deploy_testnet.sh

Follow the step-by-step walkthrough in demo/demo-script.md.

• Documentation Index — all docs/ guides grouped by topic (start here)
• Architecture Overview
• Contract Module Index — maps each contract source file to its purpose and originating issue
• Trust Slice Model
• ZK Verification Design
• Threat Model & Security
• Error Code Reference
• Integration Patterns Guide
• Quorum Slice Trust Model Guide
• Issuer Security Checklist
• Troubleshooting Guide
• Backup System
• Batch Issuance Limits
• Roadmap
• REST API Documentation Auto-Generation — OpenAPI 3.1, Swagger UI, ReDoc, TypeScript client

issue_credential(subject, credential_type, metadata_hash) -> u64
get_credential(credential_id) -> Credential
revoke_credential(credential_id)

create_slice(attestors: Vec<Address>, threshold: u32) -> u64
get_slice(slice_id) -> QuorumSlice
add_attestor(slice_id, attestor)

attest(credential_id, slice_id)
is_attested(credential_id) -> bool
get_attestors(credential_id) -> Vec<Address>

verify_claim(credential_id, claim_type, proof) -> bool
generate_proof_request(credential_id, claim_type) -> ProofRequest

Comprehensive test suite covering:

• ✅ Credential issuance and revocation
• ✅ Quorum slice creation and attestor management
• ✅ Multi-party attestation flow
• ✅ ZK conditional verification
• ✅ SBT non-transferability enforcement
• ✅ Error handling and edge cases

Run tests:

cargo test

QuorumProof uses TLA+ formal specifications to mathematically verify critical properties of smart contracts. See formal-verification/README.md for:

• CredentialIssuance.tla — Credential lifecycle safety invariants
• QuorumSliceAttestation.tla — FBA attestation and threshold enforcement
• SbtNonTransferability.tla — Soulbound token ownership immutability guarantee
• ZkVerifierVerificationTransition.tla — Stub-to-real verification migration specification

All specifications are model-checked with TLC to ensure properties hold in all reachable states. See the formal verification README for how to run checks, understand the gap analysis, and contribute new specs.

The Problem: A Mechanical Engineer licensed in Brazil applying for a role in Germany faces weeks of manual credential verification across institutions, embassies, and licensing bodies.

The Solution: QuorumProof collapses that process to a single on-chain query — verified in seconds, privacy-preserving by design.

Blockchain Benefits:

• No trusted central registry to corrupt or go offline
• Transparent attestation history, auditable by any party
• Programmable verification rules enforced by smart contracts
• Accessible to any engineer with a Stellar wallet

Target Users:

• International engineering firms hiring across borders
• Engineers seeking global mobility
• Universities and licensing bodies issuing verifiable credentials
• Governments modernizing professional certification infrastructure

• v1.0 (Current): Core SBT issuance, quorum slice model, multi-attestor signing
• v1.1: Continued ZK verification hardening, key management, and proof-format upgrades
• v2.0: Revocation registry, credential expiry, renewal flows
• v3.0: Frontend UI with Stellar wallet integration
• v4.0: Mobile app, integration with national licensing APIs

See docs/roadmap.md for details.

We welcome contributions! Please:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/amazing-feature)
3. Commit your changes (git commit -m 'Add amazing feature')
4. Push to the branch (git push origin feature/amazing-feature)
5. Open a Pull Request

See our Code of Conduct and Contributing Guidelines.

This project participates in Drips Wave — a contributor funding program! Check out:

• Wave Contributor Guide — How to earn funding for contributions
• Wave-Ready Issues — Funded issues ready to tackle
• GitHub Issues labeled wave-ready — Earn 100–200 points per issue

Issues are categorized as:

• trivial (100 points) — Documentation, simple tests, minor fixes
• medium (150 points) — Helper functions, validation logic, moderate features
• high (200 points) — Core features, ZK integrations, security enhancements

This project is licensed under the MIT License — see the LICENSE file for details.

• Stellar Development Foundation for Soroban
• The Stellar whitepaper for the FBA trust model that inspired this design
• Drips Wave for supporting public goods funding