Institutional Verification Engine
📖 Manual 🎓 Academy 💼 Clients ⚙ Ops 📋 Sales 📚 Library 🗃 Vault 📄 Templates
0 / 100
Verification Engine

Institutional Readiness Dashboard

Stress-test every claim. Validate every artifact. Score every domain.

🚨 The Principle

If you want credibility at institutional level, you don't defend your system — you stress test it. This engine forces evidence-based validation across every claim OPTKAS makes. No assumptions. No hand-waving. Every claim gets a confidence rating backed by proof requirements.

Domain Confidence Scores

⚙

Infrastructure

—
NOT ASSESSED
0 / 9 claims
⛓

XRPL

—
NOT ASSESSED
0 / 8 claims
🌠

Stellar

—
NOT ASSESSED
0 / 6 claims
⚖

Legal

—
NOT ASSESSED
0 / 6 claims
🔒

Ops Control

—
NOT ASSESSED
0 / 6 claims
🛡

Security

—
NOT ASSESSED
0 / 5 claims
📋

Sales Compliance

—
NOT ASSESSED
0 / 10 claims

Confidence Rating System

GREEN — Verified

Claim is independently verifiable with on-chain evidence, legal filings, or repository artifacts. Proof exists and has been inspected.

YELLOW — Partially Verified

Claim is plausible and supporting evidence exists, but full independent verification requires additional documentation or third-party confirmation.

RED — Unverified

Claim cannot be independently verified with available evidence. May be overstated, ambiguous, or requires documentation not yet provided.

GRAY — Not Assessed

Claim has not yet been evaluated. Click into the domain to begin assessment.

Institutional Readiness Tiers

ScoreGradeMeaning
90–100INSTITUTIONAL GRADEAll claims verified. Ready for institutional due diligence.
75–89AUDIT READYMost claims verified. Minor gaps require documentation.
60–74PROGRESSINGSignificant verification in progress. Key gaps remain.
40–59DEVELOPINGMultiple domains require evidence. Not investor-ready.
0–39EARLY STAGEInsufficient verification. Major documentation gaps.

Credibility Risk Summary

Complete at least one domain assessment to generate the credibility risk summary.

Domain A

⚙ Infrastructure Verification

28 engines • 9 accounts • 9 pools • 1,213+ tests • Cross-chain settlement

This domain validates the core technical infrastructure claims: automation engines, mainnet accounts, liquidity pools, testing coverage, and cross-chain architecture.

A1

28 Production TypeScript Engines

Claim: 28 production TypeScript engines handle bond lifecycle, risk, settlement, trading, portfolio management, covenant tracking, and AI routing.

🔎 Proof Required

  • Repository: List all 28 engine files with line counts and module exports
  • Tests: Show test coverage per engine (>80% expected)
  • Runtime: Demonstrate each engine can instantiate and execute its primary function
  • Logs: Show production execution logs for each engine within the last 30 days

✅ Verification Steps

  1. Inspect repository — count TypeScript files matching engine pattern
  2. Run test suite — verify >1,213 tests pass
  3. Check CI/CD — confirm engines build and deploy without errors
  4. Review dependency graph — verify engines are interconnected properly

⚠ Misconfiguration Risks

Engine count could include stubs, wrappers, or utility files that aren't true "production engines." Validate each engine has meaningful business logic, not just re-exports.

A2

9 Live Mainnet Accounts (6 XRPL + 3 Stellar)

Claim: 9 funded mainnet accounts — Issuer, Treasury, Escrow, Attestation, AMM Provider, Trading on XRPL; Issuer, Distribution, Anchor on Stellar.

🔎 Proof Required

  • On-chain: Provide all 9 account addresses (r... for XRPL, G... for Stellar)
  • Verification: Query each account on public explorers (xrpscan.com, stellar.expert)
  • Funding: Confirm minimum reserves are maintained (12+ XRP, 1+ XLM)
  • Configuration: Verify flags, signers, and trustlines match documented purpose

✅ Verification Steps

  1. XRPL: account_info for each of 6 addresses — verify funded, flags correct
  2. XRPL: account_lines — verify trustlines to issuer for Treasury/Escrow/AMM/Trading
  3. Stellar: GET /accounts/{id} on Horizon — verify 3 accounts exist and are funded
  4. Cross-reference: Verify each account has >0 transactions in last 90 days
A3

9 Liquidity Pools (6 XRPL + 3 Stellar)

Claim: 9 AMM liquidity pools — 6 on XRPL (each token paired with XRP) and 3 on Stellar (OPTKAS-USD pairs).

🔎 Proof Required

  • XRPL: amm_info for each of 6 token/XRP pairs — verify pool exists and has liquidity
  • Stellar: Horizon /liquidity_pools query for 3 OPTKAS-USD pools
  • Depth: Verify each pool has meaningful liquidity (>$1,000 equivalent)
  • Activity: Confirm trading activity within last 30 days
A4

Cross-Chain Atomic Settlement Engine

Claim: Cross-chain settlement engine coordinates atomic transfers between XRPL and Stellar — both succeed or both revert.

🔎 Proof Required

  • Source code: SettlementEngine source with cross-chain coordination logic
  • Tests: Integration tests showing success and failure (rollback) scenarios
  • On-chain: Paired transactions — matching hashes on XRPL and Stellar
  • Atomicity proof: Evidence of a failed cross-chain where both sides reverted

⚠ Misconfiguration Risks

True atomicity across independent chains requires hash-time-locked contracts or a trusted coordinator. Without native cross-chain atomicity, "atomic" may mean "coordinated with rollback" rather than cryptographically atomic. Clarify the mechanism.

A5

SHA-256 Dual-Chain Proof Anchoring

Claim: Every material action generates a SHA-256 hash anchored on both XRPL (memo transactions) and Stellar (manage_data operations) simultaneously.

🔎 Proof Required

  • XRPL: Show transactions with memo fields containing SHA-256 hashes
  • Stellar: Show matching hashes in manage_data key-value pairs
  • Pairing: Cross-reference — same hash on both chains with matching timestamps
  • Coverage: Define what "material action" includes and show all categories are covered
A6

1,213+ Automated Tests

Claim: Over 1,213 automated tests covering all engines and subsystems.

🔎 Proof Required

  • Test runner output: Full test suite run showing exact count and pass/fail
  • Coverage report: Line/branch/function coverage percentages
  • CI history: Last 10 CI runs showing consistent test execution
  • Quality: Review sample of 20+ tests for meaningful assertions (not trivial)
A7

70+ Pre-Flight Transaction Checks

Claim: Over 70 automated pre-flight validation checks run before any on-chain transaction executes.

🔎 Proof Required

  • Source code: Pre-flight check module with enumerated validations
  • List: Complete list of all 70+ checks with descriptions
  • Logs: Transaction logs showing pre-flight gate before submission
  • Failure examples: Show a transaction blocked by a pre-flight check
A8

10,000 Monte Carlo Risk Simulations

Claim: Continuous 10,000-iteration Monte Carlo simulations for portfolio risk assessment (VaR at 95th and 99th percentile).

🔎 Proof Required

  • Source code: RiskEngine Monte Carlo module with simulation logic
  • Output: Sample simulation output showing distribution of outcomes
  • Reproducibility: Run simulation with fixed seed — output must match expectations
  • Integration: Show risk alerts triggered by simulation results
A9

97.4% On-Chain Success Rate

Claim: 97.4% on-chain transaction success rate with retry logic handling transient failures.

🔎 Proof Required

  • Transaction log: Full transaction history with success/failure counts
  • Calculation: Show the denominator — how many total transactions attempted
  • Retry logic: Source code showing retry mechanism and backoff strategy
  • Failure analysis: Categorize the 2.6% failures — network, insufficient funds, etc.

⚠ Misconfiguration Risks

97.4% could be inflated if retried transactions count as single attempts. Clarify: is this first-attempt success rate or eventual success rate after retries?

Domain B

⛓ XRPL Capabilities Verification

Trustlines • Freeze • Multisig • Escrow • AMM • DEX • NFT Attestations

Validates that the system correctly utilizes XRPL-native features at the protocol level. Each capability requires specific ledger queries for verification.

B1

Trustline-Based Issuance

Claim: All 6 OPTKAS tokens are issued as XRPL IOUs via trustline relationships.

🔎 Proof Required

  • Ledger query: account_lines on Issuer — shows all outstanding obligations
  • Currency codes: Verify OPTKAS, SOVBND, IMPERIA, GEMVLT, TERRAVL, PETRO exist
  • Holders: account_lines on holder accounts confirms trustlines to Issuer
B2

DefaultRipple Configuration

Claim: Issuer account has DefaultRipple enabled allowing token holders to trade directly via the DEX.

🔎 Proof Required

  • Ledger query: account_info on Issuer — check lsfDefaultRipple flag (0x00800000)
  • Verification: Attempt a third-party trade — if DefaultRipple is off, trades between non-issuer accounts fail

⚠ Risk

If DefaultRipple is NOT enabled, token holders cannot trade with each other — only with the Issuer. This is a critical configuration that must be verified.

B3

Individual Freeze & Global Freeze

Claim: Issuer can freeze individual trustlines and trigger global freeze across all token holders.

🔎 Proof Required

  • Account flags: Verify lsfNoFreeze is NOT set (if set, freeze is permanently disabled)
  • Individual: Show a TrustSet transaction with freeze flag on a specific trustline
  • Global: Verify ability to set lsfGlobalFreeze via AccountSet
  • Source code: Freeze module with both individual and global freeze functions
B4

Multi-Signature Configuration

Claim: Critical accounts use 2-of-3 multisig with 3-of-3 for configuration and 1-of-3 for emergencies.

🔎 Proof Required

  • Ledger query: account_info — check SignerEntries for signer list
  • Quorum weights: Verify signer weights and quorum match 2-of-3 configuration
  • Signer keys: Confirm all 3 signers are distinct, controlled entities
  • Transaction history: Show multisig transactions with 2+ signatures
B5

Escrow Transactions

Claim: Native XRPL escrow used for conditional bond payments and DvP settlement.

🔎 Proof Required

  • Transaction types: Show EscrowCreate, EscrowFinish, EscrowCancel transactions
  • Crypto-conditions: Verify condition/fulfillment pairs for conditional escrow
  • Time-based: Show escrow with FinishAfter/CancelAfter parameters
  • DvP flow: Demonstrate end-to-end Delivery-versus-Payment using escrow
B6

XLS-30 AMM Pools

Claim: 6 live AMM pools on XRPL using the XLS-30 standard with constant-product pricing.

🔎 Proof Required

  • Ledger query: amm_info for each token/XRP pair
  • Pool depth: Verify non-trivial balance in each pool
  • LP tokens: Confirm LP token generation and AMM Provider holdings
  • Trading activity: Show AMMDeposit, AMMWithdraw, and swap transactions
B7

Native DEX Smart Routing

Claim: The XRPL auto-bridges between DEX orderbook and AMM pools for best execution.

🔎 Proof Required

  • Path finding: path_find or ripple_path_find showing multi-hop routes
  • Auto-bridging: Show Payment with Paths field using XRP as intermediary
  • AMM+DEX: Show a trade that splits between AMM pool and orderbook
B8

XLS-20 NFT Attestations

Claim: XLS-20 NFTs minted as permanent attestation certificates for material actions.

🔎 Proof Required

  • Ledger query: account_nfts on Attestation account — list all NFTs
  • Metadata: Verify NFT URI contains meaningful attestation data or hash
  • Non-transferable: Check if lsfBurnable/lsfTransferable flags match attestation purpose
  • Volume: Count total NFTs — should correlate with material actions performed
Domain C

🌠 Stellar Capabilities Verification

AUTH_REQUIRED • AUTH_REVOCABLE • CLAWBACK • manage_data • Stellar AMM

Validates Stellar-specific regulated asset features, proof anchoring via manage_data, and AMM pool presence on the Stellar network.

C1

AUTH_REQUIRED Flag

Claim: Stellar Issuer has AUTH_REQUIRED flag — every holder must be explicitly authorized.

🔎 Proof Required

  • Horizon query: GET /accounts/{issuer} — check flags.auth_required = true
  • Test: Attempt to send OPTKAS-USD to an unauthorized account — should fail
  • Authorization: Show AllowTrust or SetTrustLineFlags operations in transaction history
C2

AUTH_REVOCABLE Flag

Claim: Issuer can revoke authorization at any time — critical for compliance enforcement.

🔎 Proof Required

  • Horizon query: GET /accounts/{issuer} — check flags.auth_revocable = true
  • Operation: Show a SetTrustLineFlags operation revoking authorization
  • Effect: Confirm holder can no longer transact after revocation
C3

CLAWBACK Enabled

Claim: Issuer can clawback tokens from any holder's account — essential for regulatory enforcement.

🔎 Proof Required

  • Horizon query: GET /accounts/{issuer} — check flags.auth_clawback_enabled = true
  • Caution: Clawback must be set BEFORE any trustlines are created (Stellar rule)
  • Operation: Show a Clawback operation in transaction history (or capability to execute)

⚠ Risk

If clawback was NOT enabled before first trustline creation, it CANNOT be enabled retroactively on Stellar. This is a critical one-time configuration.

C4

Trustline Authorization Gating

Claim: All OPTKAS-USD holders are individually gated through trustline authorization before receiving tokens.

🔎 Proof Required

  • Holder accounts: Show trustlines with authorized flag set by Issuer
  • Process: Document the KYC → authorization workflow end-to-end
  • Rejection: Show evidence of an authorization being denied or revoked
C5

manage_data Proof Anchoring

Claim: SHA-256 hashes are stored as key-value pairs on Stellar via manage_data operations.

🔎 Proof Required

  • Horizon query: GET /accounts/{issuer} — inspect data field for hash entries
  • Cross-reference: Match Stellar manage_data hashes to XRPL memo hashes
  • Coverage: Verify hashes exist for all claimed material action categories
C6

Stellar AMM Pool Presence

Claim: 3 AMM pools on Stellar — OPTKAS-USD/XLM, OPTKAS-USD/USDC, OPTKAS-USD/yUSDC.

🔎 Proof Required

  • Horizon query: GET /liquidity_pools with OPTKAS-USD asset filter
  • Pool details: Verify reserves, fee structure, and total shares for each pool
  • Trading activity: Show trades or deposits within last 30 days
Domain D

⚖ Legal Structure Verification

SPV • MTN Program • UCC-1 • Bond Indenture • Transfer Agent • Insurance

Legal claims require documentary proof — filing receipts, notarized documents, and public registry lookups. Many require securities counsel validation.

D1

Wyoming SPV (OPTKAS1-MAIN LLC)

Claim: OPTKAS1-MAIN LLC is a Wyoming-registered Special Purpose Vehicle providing legal structure.

🔎 Proof Required

  • Registry lookup: Wyoming Secretary of State — search for OPTKAS1-MAIN LLC
  • Filing: Articles of Organization or Certificate of Formation
  • Good standing: Current good standing certificate from Wyoming SOS
  • Operating Agreement: LLC Operating Agreement (may be confidential but existence confirmable)
D2

$500M Medium-Term Note Program

Claim: A $500 million MTN program provides the legal framework for token issuance.

🔎 Proof Required

  • Program document: MTN Program Agreement or Offering Memorandum
  • Legal opinion: Opinion letter from securities counsel confirming program validity
  • Regulatory filing: Any SEC/state filings (Reg D, Reg S, or applicable exemptions)
  • Counsel review: This claim REQUIRES securities counsel validation

⚠ Risk

"$500M MTN Program" is a capacity claim, not a funded amount. Clarify: is this authorized capacity or deployed capital? Investors may misinterpret this as assets under management.

D3

UCC-1 Lien Filed

Claim: UCC-1 financing statement filed with Wyoming Secretary of State establishing first-priority secured claims.

🔎 Proof Required

  • Public search: Wyoming SOS UCC search — locate filing by debtor name (OPTKAS1-MAIN LLC)
  • Filing receipt: UCC-1 financing statement with filing number and date
  • Collateral description: Verify collateral described matches platform assets
  • Priority: Confirm no prior liens exist (first-priority claim)
  • Continuation: Verify filing is current (UCC filings expire after 5 years without continuation)
D4

Bond Indenture

Claim: Master Bond Indenture governs all token rights, obligations, and redemption terms.

🔎 Proof Required

  • Document: Executed Bond Indenture with all parties' signatures
  • Terms: Coupon rate, maturity, redemption, waterfall, default provisions
  • Trustee: If applicable, identify the indenture trustee (if TIA applies)
  • Counsel: Legal opinion confirming enforceability — REQUIRES securities counsel
D5

Transfer Agent (Securities Transfer Corporation)

Claim: Securities Transfer Corporation serves as independent transfer agent maintaining the bondholder register.

🔎 Proof Required

  • Agreement: Transfer Agent Agreement between STC and OPTKAS1-MAIN LLC
  • SEC registration: Verify STC is SEC-registered transfer agent (EDGAR lookup)
  • Active service: Confirm STC is currently maintaining records (not just contracted)
  • Records: Sample bondholder register entry (redacted for privacy)
D6

$25.75M Insurance Coverage

Claim: $25.75 million blanket crime, error, and omissions insurance policy.

🔎 Proof Required

  • Policy: Insurance policy declarations page showing coverage amount and type
  • Carrier: Identify the insurance carrier (must be A-rated or better)
  • Coverage scope: Verify policy covers digital asset operations specifically
  • Active status: Certificate of insurance showing current effective dates
  • Exclusions: Review exclusions — many policies exclude crypto-specific risks

⚠ Risk

Insurance policies for digital assets are rare and expensive. Verify the policy specifically covers blockchain-based securities operations, not just general business liability. Many standard E&O policies exclude digital assets.

Domain E

🔒 Operational Control Verification

Mint • Burn • Freeze • Revoke • Clawback • Kill Switch

Validates that the Issuer has exclusive, functional control over all claimed operational powers. Each requires transaction-level and source code inspection.

E1

Mint Control Exclusivity

Claim: Only the Issuer account can create new tokens. No other account can mint.

🔎 Proof Required

  • XRPL native: This is inherent — only the Issuer's negative balance creates IOUs (protocol-level)
  • Verification: Confirm no other accounts have been designated as issuers for the same currency codes
  • Source code: Verify mint functions only use the Issuer account's credentials
E2

Burn Mechanism

Claim: Tokens received by the Issuer are automatically destroyed (burned), reducing supply.

🔎 Proof Required

  • XRPL native: This is inherent — IOUs sent to the Issuer reduce the Issuer's obligations
  • Verification: Show before/after account_lines on Issuer — obligations decrease after receiving tokens
  • Process: Document the burn workflow — who triggers it, under what conditions
E3

Freeze Capability

Claim: Issuer can freeze individual trustlines and trigger global freeze across all holders.

🔎 Proof Required

  • Account flags: Confirm lsfNoFreeze is NOT set on Issuer account
  • Source code: Freeze functions with individual and global freeze logic
  • SPOF risk: Is the freeze key held by a single person? Should require multisig
E4

Stellar Revocation & Clawback

Claim: Issuer can revoke Stellar authorization and clawback tokens from any holder.

🔎 Proof Required

  • Flags: Confirm auth_revocable and auth_clawback_enabled on Stellar Issuer
  • Operations: SetTrustLineFlags (revoke) and Clawback operations in source code
  • Test: Demonstrate revocation and clawback on testnet or show mainnet evidence
E5

Global Trading Halt

Claim: Ability to halt all trading globally across both XRPL and Stellar in an emergency.

🔎 Proof Required

  • XRPL: Global freeze via AccountSet with lsfGlobalFreeze flag
  • Stellar: Revoke all holders' authorization via SetTrustLineFlags batch
  • Coordination: Source code showing combined cross-chain halt procedure
  • SPOF: Can 1-of-3 signers trigger this? Verify emergency access controls
E6

Circuit Breaker Logic

Claim: 5% circuit breaker pauses trading; 10% kill switch halts all operations.

🔎 Proof Required

  • Source code: TradingEngine with circuit breaker and kill switch thresholds
  • Configuration: Verify thresholds are configurable and currently set to 5%/10%
  • Trigger log: Show a circuit breaker trigger event (production or backtest)
  • Recovery: Document the re-enable process after a circuit breaker triggers
Domain F

🛡 Security & Risk Controls Verification

Multisig • Kill Switch • Circuit Breaker • Default Protocol • Monte Carlo

Security claims require cryptographic validation, simulation reproducibility, and monitoring log inspection. These are the hardest claims to verify — and the most important.

F1

Multi-Sig Governance (2-of-3 / 3-of-3 / 1-of-3)

Claim: 2-of-3 for transactions, 3-of-3 for configuration changes, 1-of-3 for emergency freeze.

🔎 Proof Required

  • Signer list: account_info showing SignerEntries and quorum weights
  • Three tiers: Source code implementing separate quorum levels per action type
  • Key separation: Confirm 3 signers are distinct individuals/entities (not shared keys)
  • Emergency: Verify 1-of-3 can only trigger freeze (not move funds or change config)

⚠ Risk

XRPL natively supports only a single quorum threshold per account. Multiple tiers (2-of-3, 3-of-3, 1-of-3) may require application-layer enforcement, not protocol-level. Clarify which tier is protocol vs. application.

F2

Kill Switch

Claim: Kill switch halts all trading when losses exceed 10% of portfolio value.

🔎 Proof Required

  • Source code: Kill switch implementation with 10% threshold
  • Monitoring: Show real-time PNL tracking that feeds the kill switch
  • Action: What exactly happens when triggered — halt engine, freeze accounts, both?
  • Recovery: What's the re-enable process? Who approves it?
F3

Automated Default Response Protocol

Claim: Automated multi-step default protocol: detect → alert → freeze → revoke → liquidate → distribute.

🔎 Proof Required

  • Source code: Full default protocol implementation with sequential trigger logic
  • Detection: What conditions trigger default detection? Specific thresholds?
  • Liquidation: Who controls liquidation? Automated or manual? Under whose authority?
  • Legal basis: Bond Indenture provisions authorizing the default process
  • Logging: Every step must be logged and anchored on-chain for audit
F4

Continuous Monte Carlo Stress Testing

Claim: 10,000-iteration Monte Carlo simulations run continuously for portfolio risk monitoring.

🔎 Proof Required

  • Reproducibility: Run simulation with seed=42 — output must be deterministic
  • Distribution: Show the output probability distribution (histogram or percentile table)
  • VaR output: Show Value at Risk at 95th and 99th confidence levels
  • Schedule: How often does "continuously" mean? Every minute? Hour? Day?
  • Alerting: Show an alert triggered by a Monte Carlo result exceeding threshold
F5

Monitoring & Logging Infrastructure

Claim: All operations are logged, hashed, and anchored on-chain. Real-time dashboards for all system metrics.

🔎 Proof Required

  • Logging: Show structured log output from multiple engines with timestamps
  • Hash chain: Show SHA-256 hash of log entries anchored on-chain
  • Dashboards: Screenshot or demo of real-time monitoring dashboards
  • Alerting: Show alert configuration and at least one triggered alert
  • Retention: What is the log retention policy? How long are logs kept?
Domain G

Sales & Solicitation Compliance

7 claims · Validates that all sales processes, scripts, training, and compensation structures meet institutional standards.

G1

Sales Scripts Versioned & Approved

Claim: All sales scripts are version-controlled, approved by compliance, and tracked for updates. Solicitors use only current approved versions.

🔎 Proof Required

  • Version control: Show timestamped script versions in a repository or document management system
  • Approval chain: Demonstrate compliance sign-off on each script version
  • Distribution log: Show that solicitors received and acknowledged current versions
  • Retirement: Confirm old versions are marked deprecated and inaccessible
G2

Approved Claims Library Published

Claim: A comprehensive library of approved claims (verified facts, operational processes, forward-looking disclosures) is published, accessible to all solicitors, and categorized by the Three Buckets rule.

🔎 Proof Required

  • Library existence: Show the published Claims Library with all approved statements
  • Categorization: Confirm each claim is tagged to its bucket (Verified Fact, Operational Process, Forward-Looking)
  • Accessibility: Demonstrate solicitors can access the library during client interactions
  • Currency: Show last-reviewed date and update frequency for the library
G3

Forbidden Phrases Documented

Claim: All prohibited statements (F-01 through F-12) are documented, published, and tested in the Sales Academy exam with a 90% pass threshold on the forbidden statements section.

🔎 Proof Required

  • Documentation: Show the complete forbidden phrases list with identifiers F-01 through F-12
  • Training integration: Demonstrate the forbidden phrases are tested in the final certification exam
  • Threshold enforcement: Confirm 90% pass threshold is enforced on the forbidden statements section
  • Consequence documentation: Show that using a forbidden phrase triggers immediate disqualification
G4

Sales Academy Completion Gating

Claim: No solicitor can conduct sales outreach without completing the 10-lesson Sales Academy, passing all quizzes (70%+), signing all attestations, and passing the 50-question final exam (85% overall, 90% on forbidden statements).

🔎 Proof Required

  • Curriculum: Show the 10-lesson curriculum with quiz requirements for each lesson
  • Final exam structure: Demonstrate the 50-question exam with section scoring
  • Gating enforcement: Show that certification is required before sales contact is permitted
  • Expiration: Confirm 90-day certification expiry and recertification process
  • Retake policy: Show 24-hour cooldown on exam retakes
G5

Compensation Structure Documented

Claim: Solicitor compensation is fully documented and disclosed. Compensation is never tied to investment performance or returns. Volume-based bonuses and return-tied commissions are explicitly prohibited.

🔎 Proof Required

  • Compensation schedule: Show the published compensation structure (onboarding fee share, platform service share)
  • Prohibition clauses: Show written prohibition of volume bonuses and performance-tied compensation
  • Solicitor Disclosure Form: Demonstrate the form disclosing compensation to prospects before agreement signing
  • Audit trail: Show that compensation payments are logged and reconcilable
G6

BD/Licensing Pathway Defined

Claim: The broker-dealer (BD) registration or exemption pathway is clearly defined and documented. Current licensing status is transparently disclosed to prospects.

🔎 Proof Required

  • Pathway documentation: Show the BD registration/exemption strategy with timeline
  • Current status: Clearly state current licensing status (e.g., solicitor exemption, pending registration)
  • Legal opinion: Show legal counsel's opinion on current operating authority
  • Disclosure to prospects: Demonstrate that licensing status is disclosed during onboarding
G7

Risk Disclosures Attached to All Pitch Materials

Claim: All 7 material risk categories are documented and attached to every set of pitch materials. No sales presentation occurs without risk disclosures being made available and walked through.

🔎 Proof Required

  • Risk categories: Show all 7 risk categories (Market, Liquidity, Regulatory, Technology, Counterparty, Operational, Total Loss)
  • Attachment proof: Demonstrate risk disclosures are physically attached to all pitch decks and materials
  • Walk-through log: Show records confirming risk disclosures were reviewed with each prospect
  • Acknowledgment: Show signed acknowledgment from prospects that they received and understood risk disclosures
G8

Marketing Materials Version-Controlled

Claim: All outbound marketing materials (pitch decks, one-pagers, email templates, social media copy) are centrally version-controlled. No material may be distributed without a current-version stamp and compliance sign-off.

🔎 Proof Required

  • Version control system: Show the repository or document management system with version history
  • Sign-off workflow: Demonstrate the compliance approval process before distribution
  • Audit trail: Show log of who distributed which version to whom and when
  • Recall procedure: Document the process for recalling outdated materials from circulation
G9

Outbound Emails Use Approved Templates Only

Claim: All outbound communications to prospects, leads, and clients use pre-approved email templates. Freeform cold outreach is prohibited unless individually approved by compliance. Template library is reviewed and updated quarterly.

🔎 Proof Required

  • Template library: Show the approved email template repository with version dates
  • Enforcement mechanism: Demonstrate technical controls preventing unapproved templates (e.g., CRM lockdown)
  • Quarterly review log: Show records of template library reviews with dates and sign-offs
  • Exception process: Document the approval workflow for any non-template communications
G10

Compensation Structure Reviewed by Counsel

Claim: All sales compensation structures, commission tiers, and performance bonuses have been reviewed by external securities counsel to ensure they do not create incentive structures that could be deemed manipulative or in conflict with fiduciary obligations.

🔎 Proof Required

  • Compensation plan: Show the current sales compensation structure document
  • Counsel review letter: Provide legal counsel's written review and approval of the compensation plan
  • Conflict analysis: Show documentation analyzing potential conflicts of interest in the incentive structure
  • Annual re-review: Demonstrate that compensation structures are re-reviewed at least annually
G11

User Registration + Encrypted Training Records Enabled

Claim: The platform enforces cryptographic registration before accessing training materials. Each registrant is assigned an ECDSA P-256 keypair, a passphrase-encrypted private key stored in IndexedDB, and a hash-chain audit trail that records every training event with tamper-resistant integrity. Quiz and exam completions are cryptographically signed as attestations that can be independently verified.

🔎 Proof Required

  • Registration gate: Demonstrate that Sales Academy, Vault, and Templates pages block access until registration is complete
  • Keypair generation: Show ECDSA P-256 keypair generation via WebCrypto API in optkas-crypto.js
  • Encrypted storage: Confirm private key is encrypted with PBKDF2 (600k iterations) + AES-GCM-256 before IndexedDB storage
  • Hash-chain audit: Verify audit chain integrity using OPTKAS_AUDIT.verifyChain() — all event hashes must validate
  • Signed attestations: Show at least one quiz or exam attestation with valid ECDSA signature verification
  • Document locker: Demonstrate role-based and jurisdiction-based document access filtering