ADVISOR EVIDENCE PORTFOLIO

Decentralized Architecture Evidence

Dr. Dragan Bošković — Blockchain Research Lab, ASU SCAI

9 deployed smart contracts · AI orchestration pipeline · earned-only token model · permissionless design

Public Ethereum (Sepolia) All Contracts Verified Phase 1 Demonstration Patent Pending 64/063,037 · 64/106,748

01 9 Deployed Smart Contracts

All contracts deployed on Ethereum Sepolia testnet. Each row links to Blockscout verification. Deployer: 0xf22c...eF248 (primary) except where noted.

#ContractAddressStandardPurposeVerified
1 HypnoNeuroToken (HNT) 0x1ae1...84e2 ERC-20 Earned-only wellness engagement token Verified
2 EHTv2 0x9358...0d88 ERC-20 Platform token (144K cap) Verified
3 HypnoNeuroNFT 0xCb9E...7771 ERC-1155 3-level achievement credentials Verified
4 SovereignLedger v2 0x4afA...aCc4 Custom Session governance — claims, verification, pause Verified
5 AlchemistForge 0x5e17...3c3B Custom Permissionless engagement recording + document archival Verified
6 BenevolenceFund v3 0x804C...2C50 Custom 3% session fee — 44/33/22/1 community treasury Verified
7 SovereignAchievement 0xC3F1...9B8D ERC-1155 Soulbound credentials — 20 tiers Verified
8 NeuroBalanceConsent 0x2157...96b8 Custom Biosensor consent scaffold (deployed, integration pending) Verified
9 SovereignSession 0xbeb1...65A1 Custom Session attestation (deployer-signed; guide-initiated signing is Phase 5) Bytecode only

SovereignSession: source verification pending — local source at fsl-governance/contracts/sovereign-session/ (private repo).

02 Autonomous Agent Pipeline

Review Agents (17)

Every document (Blockchain in Healthcare Today (BHTY) paper, LOI, CV) passes through a AI autonomous review before submission. Each agent has a defined review domain:

#AgentReview Domain
1Peer ReviewerMethodology, academic rigor
2Legal ComplianceRegulatory framing, HIPAA scope
3CryptographyEIP correctness, crypto primitives
4Smart ContractSolidity, on-chain architecture
5System ArchitectOverall system design
6Academic WritingClarity, structure, citations
7Clinical EthicsIRB, participant safety
8Brand ConsistencyTerminology, naming conventions
9DevOpsDeployment, infrastructure
10DatabaseSchema, data model
11DocumentationCompleteness, accuracy
12NatPsyNaturopathic psychology domain
13Legal / IPPatent, trademark, disclosure
14Marketing / CommsPositioning, messaging
15UXUser experience, accessibility
16Data ScienceAnalytics, ML readiness
17GovernancePolicy, access control
Operational Agents (15)

Separate from the review pipeline, 15 operational agents handle live system tasks. Agents route through OpenRouter with per-model cost tracking.

#AgentDomain
1AuditSystem audit, compliance checks
2System ArchitectArchitecture decisions
3BackendAPI, server logic
4FrontendUI, client application
5Smart ContractSolidity, on-chain ops
6DatabaseSchema, migrations
7ComplianceRegulatory, privacy
8SecurityThreat model, hardening
9TestingQA, test coverage
10DocumentationDocs, changelogs
11Approval GateDeploy approval routing
12HypnoNeuroWellness game platform
13Game ArchitectL1/L2/L3 game design
14NatPsy AdvisorNaturopathic psychology
15OrthomolecularAmino acid protocols

03 HNT Earned-Only Token Model

Non-Purchasable, Wellness-Engagement-Only Minting

HypnoNeuroToken (HNT) is earned through session completion — not purchased. No ICO, no presale, no speculative holding, no liquidity pool. The token exists as a sovereign governance instrument, not a financial asset. Owner-minted on verified session completion via SovereignLedger attestation.

Design Rationale

The earned-only model is a deliberate architectural choice that removes speculative incentives from the governance layer. Participants earn HNT by engaging with the wellness framework — the token reflects verified engagement, not capital allocation. This aligns token distribution with system participation rather than market dynamics.

04 BenevolenceFund 44/33/22/1 Distribution

44%
1st Place Guide
33%
2nd Place Guide
22%
3rd Place Guide
1%
Top Participant

3% of every session fee routes to the BenevolenceFund contract. Annual distribution follows the 44/33/22/1 model — a community treasury governed by on-chain rules, not discretionary allocation. Contract: 0x804C...2C50.

05 3 Open-Source Contributions

RepositoryPRStatus
bcgov/aries-vcr#811Merged
openmrs/openmrs-module-fhir2#577Open
openmrs/openmrs-contrib-fhir2-ig#63Open

06 SovereignLedger Session Governance

Objective: A single wallet-signed consent architecture that simultaneously solves security, privacy, clinical governance, and blockchain infrastructure. Your domain: the smart-contract layer + HKDF key derivation that makes this architecture enforceable and the token economics deployable. The consent primitive (Dr. Ahn) depends on your engineering to become a working system. Patents: U.S. Provisional 64/063,037 (single-signer EIP-191 consent, zero-PHI constraint, Sovereign Guide attestation; CIP planned October 2026) and 64/106,748 (bilateral dual-signature protocol with HKDF session-key derivation, filed July 2026).

On-Chain Session Attestation

SovereignLedger v2 records session attestations via registerClaim. Currently deployer-signed (server-authoritative); guide-initiated signing is the Phase 5 doctoral contribution. Contract: 0x4afA...aCc4.

Where I Am: Working Pipeline

The session → mint → attestation pipeline is built and demonstrated:

  • Session completion triggers server-side processSessionReward (deployer-signed) → 1 HNT minted to participant wallet (on-chain ERC-20)
  • Session recorded in sovereign_sessions DB → registerClaim(claimId, claimHash) on SovereignLedger (Sepolia)
  • NFT achievement milestones at 3/6/9 sessions (ERC-1155)
  • Evidence: 7 sessions recorded, 3 with on-chain attestation hashes, HNT minted to participant wallets

Honest disclosure: Today’s attestation is deployer-signed (the server writes to the contract after session completion). The participant does not wallet-sign the attestation. This is the working substrate that Phase 5 extends.

Phase 5 — The Ask: HKDF Key Derivation + On-Chain Engineering

Open problem: HKDF-derived AES-256-GCM client-side encryption (HKDF-derived from both parties’ EIP-712 signatures) for session recordings, where no single party — including FSL — can decrypt unilaterally. Plus the on-chain smart-contract architecture binding bilateral consent to session governance and token distribution.

Why this is hard: HKDF key derivation tied to wallet-signed consent is unsolved cryptographic + contract engineering. Existing threshold schemes (FROST, GG18/GG20) solve multi-party signing, not session-encryption-key derivation from bilateral consent signatures. Adapting these primitives to a consent context — where the key must be derivable only when both parties have signed — is the open problem.

What I need from your lab: Dr. Bošković’s Blockchain Research Lab expertise in HKDF key derivation and on-chain data structures to design the encryption-key-derivation scheme and the contract infrastructure that binds it to the bilateral consent primitive. The consent primitive formalization is Dr. Ahn’s domain (co-advisor); the ecosystem architecture, smart-contract engineering, and on-chain verification are Dr. Boscovic’s domain as primary advisor.

Unsolved Primary advisor domain: HKDF key derivation + contract engineering

What’s Needed for Full Deployment

The HKDF key-derivation scheme, multisig contract migration (single deployer → quorum governance), and the 70/27/3 distribution contract under mainnet economics. Without the key-derivation engineering, bilateral consent has no encryption layer. Without multisig governance, the nine-contract deployment stays centralized. Your advisement unlocks both.

07 Architectural Design Choices

Dual-Chain Architecture

Public Ethereum (Sepolia) primary chain for smart contracts and attestation. XRPL scaffolded for future multi-chain payment acceptance (mainnet wallet active for readiness; settlement integration planned). IPFS-pinned, wallet-access-gated off-chain storage for data sovereignty.

Open Registration Model

SovereignLedger uses open registration (not owner-gated). AlchemistForge is fully permissionless — no admin, no owner, no pause. Trust-minimized design demonstrating participant agency over platform control.

Zero-Custodial SDK

Browser-extension wallets connect via EIP-6963 with zero SDKs or relays. An optional WalletConnect v2 path (Reown AppKit) is offered for mobile/multi-device access; the relay transports encrypted messages but holds no keys. No Privy, no third-party key custody. Private keys never leave the user’s device on either path.

Single-Practitioner Build

The entire 9-contract ecosystem, 5-platform infrastructure, AI review pipeline, and 15 operational agents were designed and deployed by a single practitioner-engineer working outside institutional funding. AI-augmented engineering with full human oversight.

08 Research Convergence

Why This Matters to the Blockchain Research Lab

Your lab has explored decentralized healthcare data architectures for participant-controlled data sovereignty. FSL arrives at convergent conclusions through a different cryptographic stack — public Ethereum with EIP-191 wallet-signed consent. The convergence validates the problem framing while the architectural divergence creates a natural comparison study.

I need your lab’s expertise in HKDF key derivation and on-chain data structures to design the key-derivation scheme that makes bilateral consent enforceable at the encryption layer. The nine-contract deployment provides the working substrate; the HKDF-derived session-key encryption is the unsolved engineering problem I am asking you to co-advise.

The token economics (70/27/3 platform split, earned-only HNT distribution, BenevolenceFund governance) and permissionless contract design (AlchemistForge) sit squarely in your research domain and are ready for formal analysis.