Skip to main content

​
Smart Contracts

Sphyre’s on-chain layer lives in fortro-contract-dev/hardhat/contracts and is consumed by Fortro Engine through ABI files copied into fortro-engine/src/blockchain/abis.

Network

Target: Base Sepolia
Chain ID: 84532
Client: ethers via Fortro Engine

Backend Contract Client

fortro-engine/src/blockchain/client.rs binds to SSIRegistry.json and calls the aggregate registry contract.

​
Contract Inventory

ContractPurpose
SSIRegistry.solAggregate registry implementing credential, schema, consent, DID, role, and metadata operations.
CredentialRegistry.solRegisters credential hashes, revokes credentials, and exposes registered/revoked checks.
SchemaRegistry.solRegisters schema hashes, updates schema versions, and exposes schema lookups.
ConsentRegistry.solGrants, revokes, validates, and reads consent records keyed by holder, verifier, and purpose.
AccessControl.solDefines SphyreAccessControl roles for admin, issuer, holder, verifier, and relayer accounts.
ERC2771Context.solTrusted-forwarder context helper for meta-transaction sender resolution.
MinimalForwarder.solEIP-712 style forwarder with nonce, signature verification, and execution support.
SSIRegistryFactory.solCreates new SSIRegistry instances and lists deployed registries.
ISSIRegistry.solInterface covering credential, schema, and consent registry operations.

​
Roles

SphyreAccessControl defines these role constants: 
ADMIN_ROLE
ISSUER_ROLE
HOLDER_ROLE
VERIFIER_ROLE
RELAYER_ROLE
Credential and schema write operations require issuer authority. Admins manage issuer, holder, verifier, and relayer role assignments.

​
Registry Operations

registerCredential(did, credentialHash)
revokeCredential(did, credentialHash)
isCredentialRegistered(did, credentialHash)
isCredentialRevoked(did, credentialHash)

registerSchema(schemaId, schemaHash)
getSchemaHash(schemaId)
isSchemaRegistered(schemaId)

grantConsent(userDid, verifierDid, purpose, dataCategories, accessLevel, expiresAt)
revokeConsent(userDid, verifierDid, purpose)
isConsentValid(userDid, verifierDid, purpose)

registerHolderDID(holderDid, holder, didDocCid)
registerIssuerDID(issuerDid, issuer, didDocCid)
registerVerifierDID(verifierDid, verifier, didDocCid)
getDIDInfo(did)

​
Fortro Engine Routes

The active blockchain API is implemented in fortro-engine/src/api/blockchain_new.rs: 
POST /api/blockchain/credential/register
POST /api/blockchain/credential/revoke
GET  /api/blockchain/credential/check/:did/:credential_hash
POST /api/blockchain/schema/register
POST /api/blockchain/consent/grant
POST /api/blockchain/consent/revoke
GET  /api/blockchain/consent/check/:user_did/:verifier_did/:purpose
GET  /api/blockchain/status
/api/blockchain-legacy remains mounted for older flows and meta-transaction helper endpoints.

​
Configuration

Fortro Engine reads blockchain configuration from environment variables: 
BLOCKCHAIN_RPC_URL
BLOCKCHAIN_CHAIN_ID
BLOCKCHAIN_DEPLOYER_PRIVATE_KEY
SSI_REGISTRY_ADDRESS
MINIMAL_FORWARDER_ADDRESS
SSI_FACTORY_ADDRESS
BLOCKCHAIN_CHAIN_ID must match the connected RPC chain. The code validates the chain ID before constructing the contract client.

​
Data Anchoring Model

  • Credential issuance anchors credential_hash against the subject DID.
  • Credential revocation checks and revokes the same DID/hash pair.
  • Schema creation anchors schema IDs to schema hash/URI values.
  • Consent grants and revocations are keyed by holder DID, verifier DID, and purpose.
  • Verification flows use on-chain credential registration and revocation checks as one layer of validation.

​
Operational Notes

  • Backend database state remains the source for rich credential metadata; contracts anchor integrity, status, role, and consent facts.
  • Smart-contract calls can fail independently from MongoDB/IPFS writes. Backend handlers log blockchain failure and may continue for selected issuance and revocation flows.
  • ABI files must be regenerated and copied into fortro-engine/src/blockchain/abis whenever Solidity function signatures change.