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.