Qorbit

A Soroban smart contract that verifies ML-DSA (Dilithium3) post-quantum signatures on the Stellar network.

Built on NIST FIPS 204 — a quantum-resistant digital signature standard.

What it does

Exposes a single verify(message, signature, public_key) entry point that any Soroban contract or dApp can call to verify a Dilithium3 signature on-chain.

Why it matters

Classical Ed25519 signatures are vulnerable to quantum attacks. Qorbit provides an application-layer PQ verification primitive today, before Stellar's core protocol upgrades.

Usage

// Returns VerifyResult::Valid or VerifyResult::Invalid(VerifyError)
QorbitContract::verify(env, message_bytes, signature_bytes, public_key_bytes)

Key sizes (Dilithium3):

• Public key: 1952 bytes
• Signature: 2701 bytes

Current Features

• verify(message, signature, public_key) — single ML-DSA (Dilithium3) signature verification
• batch_verify(entries) — verify multiple (message, sig, pk) tuples in one call
• Structured error codes — InvalidPublicKey, InvalidSignature, SignatureMismatch
• Soroban events emitted on every verify success and failure
• On-chain trusted key registry with admin add_key / remove_key

Roadmap

These are the features that make Qorbit different from every other PQ verifier on Stellar. Each is tracked as an open issue — contributors are welcome to pick one up.

1. Signature Expiry / Time-Bounded Keys — Issue #1

Register a public key with an expiry ledger sequence. verify() automatically rejects signatures from expired keys — no manual admin intervention needed.

2. Verify-and-Execute Pattern — Issue #2

A verify_then_call(message, sig, pk, contract_id, fn_name, args) entry point that verifies the PQ signature and cross-contract calls the target only if valid. Turns Qorbit into a PQ-gated execution layer.

3. Signature Replay Protection — Issue #3

Store a nullifier (hash of the signature) on-chain and reject any signature that has already been verified. Prevents replay attacks that most verifier contracts ignore entirely.

4. Multi-Algorithm Routing — Issue #4

Accept an algorithm: AlgoType parameter and route to Dilithium2, Dilithium3, Dilithium5, or FALCON. Callers choose their own security/size tradeoff.

5. Threshold Verification — Issue #5

verify_threshold(entries, min_valid) — pass N (message, sig, pk) tuples and a minimum threshold. Returns Valid only if at least min_valid signatures pass. Enables M-of-N PQ multisig as a primitive.

6. On-Chain Audit Log — Issue #6

Store every verification result (caller, pk fingerprint, ledger sequence, outcome) in a capped ring buffer. Queryable history without needing an external indexer.

7. Key Rotation with Continuity Proof — Issue #7

rotate_key(old_pk, new_pk, rotation_sig) — the new key is accepted only if the rotation message is signed by the old key. Cryptographically enforced rotation, not just admin override.

Contributing

Each roadmap item above has a corresponding GitHub issue. To contribute:

1. Pick an open issue from the list above.
2. Comment on the issue to claim it before starting work.
3. Fork the repo, implement the feature with tests, and open a PR referencing the issue (e.g. closes #3).
4. All PRs must include at least one test covering the happy path and one covering the failure case.

See CONTRIBUTING.md for code style and PR guidelines.

Build

cargo build --target wasm32-unknown-unknown --release

Test

cargo test

Deploy

stellar contract deploy \
  --wasm target/wasm32-unknown-unknown/release/qorbit.wasm \
  --network testnet

License

MIT