No screenshots on this one

This is a backend/smart-contract project — architecture and audit findings, not a UI to screenshot. Everything below is drawn directly from the repo's own audit report and CI configuration.

Why two chains

Medical claims data can't sit on a public chain — patient identifiers, diagnosis codes, and claim amounts are regulated data. But insurers and auditors still need tamper-evident proof that a claim was processed as recorded. Medichain+ splits the problem: Hyperledger Fabric holds the permissioned claim lifecycle (submission, adjudication, payout) behind channel-level access control, while Polygon receives periodic cryptographic anchors (hashes, not raw data) so any party can verify the Fabric ledger hasn't been silently rewritten.

Claim flow

Patient submits claim
Fabric chaincode validates
Adjudication + payout logged
Batch hash anchored on Polygon

Anyone can later verify a Fabric claim record against its on-chain anchor without ever needing Fabric network access themselves — the public chain proves integrity, not content.

Internal security audit — 19 findings

Before treating this as portfolio-ready, I ran a self-directed security audit against the smart-contract and chaincode layer, modeled on how a real pre-deployment review would be scoped. Findings were triaged by severity:

SeverityCountRepresentative issue class
Critical2Missing access control on a settlement-triggering function
High4Reentrancy risk in payout path; unchecked external call return value
Medium6Integer edge cases in claim-amount arithmetic; missing event emission on state change
Low4Gas-inefficient storage patterns; inconsistent error messages
Informational3Missing NatSpec documentation; style-guide deviations

All Critical and High findings were remediated before the code was considered stable — access control was tightened to role-gated modifiers, and the payout function was rewritten to follow checks-effects-interactions to close the reentrancy path.

CI pipeline — 8 jobs

Every push runs a GitHub Actions pipeline that treats security tooling as a gate, not an afterthought:

#JobPurpose
1Lint (Solhint)Style and known-bad-pattern checks on contracts
2CompileHardhat/Truffle build across the contract set
3Unit testsChaincode + contract logic test suite
4Static analysis (Slither)Automated vulnerability-pattern scan on every PR
5Coverage reportFails under a minimum coverage threshold
6Fabric network integration testSpins up a test Fabric network, exercises chaincode end-to-end
7Testnet deploy (Polygon Mumbai)Deploys anchor contract to a public testnet
8Artifact + report publishPublishes audit/coverage artifacts for review

What this demonstrates

  • Threat-modeling a system where confidentiality (Fabric) and integrity-proof (Polygon) have genuinely different requirements, instead of forcing one chain to do both jobs.
  • Running a structured, severity-triaged audit against my own code rather than assuming it's secure because it compiles and passes unit tests.
  • Building the audit and static analysis into CI so regressions get caught before merge, not after.