Add crypto protocol cohort V0.3.1 export
This commit is contained in:
Daniel Maddern
parent
3f8e994835
commit
54ffe92018
2 changed files with 5255 additions and 0 deletions
4719
docs/crypto_venture_cohort_v031_20260816.json
Normal file
4719
docs/crypto_venture_cohort_v031_20260816.json
Normal file
File diff suppressed because it is too large
Load diff
536
docs/crypto_venture_cohort_v031_20260816.md
Normal file
536
docs/crypto_venture_cohort_v031_20260816.md
Normal file
|
|
@ -0,0 +1,536 @@
|
||||||
|
# CRYPTO VENTURE COHORT V0.3.1
|
||||||
|
|
||||||
|
Cohort ID: `CPV031-20260816215626-66d636b2`
|
||||||
|
GraphRun: `10`
|
||||||
|
Raw protocols generated: `20`
|
||||||
|
Raw Sol theses: `20`. Onchain passed: `11`. Onchain rejected: `9`.
|
||||||
|
Token design attempts: `11`. Token design skipped: `9`.
|
||||||
|
Token unnecessary: `5`. Token optional/routed SaaS: `0`. Token strongly justified: `1`. Token essential: `5`. Duplicates: `0`.
|
||||||
|
Crypto survivors: `6`. Autonomous crypto survivors: `0`. Assisted high-potential: `0`. Security-blocked: `0`. Finalists: `0`.
|
||||||
|
Generation attempts: `20`
|
||||||
|
|
||||||
|
## Runtime
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"raw_theses": 20,
|
||||||
|
"raw_target": 20,
|
||||||
|
"raw_generated": 20,
|
||||||
|
"raw_sol_theses": 20,
|
||||||
|
"requested_protocol_count": 20,
|
||||||
|
"generation_attempts": 20,
|
||||||
|
"accepted_protocols": 20,
|
||||||
|
"duplicate_rejections": 0,
|
||||||
|
"token_necessity_rejections": 0,
|
||||||
|
"generation_sources": [
|
||||||
|
"sol"
|
||||||
|
],
|
||||||
|
"model_usage": {
|
||||||
|
"sol_generation_requests": 20,
|
||||||
|
"sol_onchain_judge_requests": 20,
|
||||||
|
"sol_protocol_architecture_requests": 11,
|
||||||
|
"sol_token_design_requests": 11,
|
||||||
|
"sol_token_utility_judge_requests": 11,
|
||||||
|
"sol_final_ic_requests": 6,
|
||||||
|
"qwen_requests": 0
|
||||||
|
},
|
||||||
|
"sol_generation_requests": 20,
|
||||||
|
"sol_onchain_judge_requests": 20,
|
||||||
|
"fallback_count": 0,
|
||||||
|
"onchain_rejected": 9,
|
||||||
|
"onchain_passed": 11,
|
||||||
|
"crypto_survivors_after_onchain": 11,
|
||||||
|
"token_design_skipped_due_to_onchain_rejection": 9,
|
||||||
|
"token_unnecessary_rejections": 5,
|
||||||
|
"token_optional_route_to_saas": 0,
|
||||||
|
"token_essential": 5,
|
||||||
|
"token_strongly_justified": 1,
|
||||||
|
"serious_crypto_survivors": 6,
|
||||||
|
"crypto_survivors": 6,
|
||||||
|
"token_design_attempts": 11,
|
||||||
|
"token_design_count_matches_onchain_passed": true,
|
||||||
|
"sol_token_design_requests": 11,
|
||||||
|
"sol_token_utility_judge_requests": 11,
|
||||||
|
"crypto_novelty_removed": 0,
|
||||||
|
"hard_exclusion_rejections": 0,
|
||||||
|
"regeneration_attempts": 0,
|
||||||
|
"regenerated_protocols": 0,
|
||||||
|
"unfilled_slots_after_regeneration": 14,
|
||||||
|
"regeneration_policy": "V0.3.1 uses total raw Sol generation budget; offchain or weak token ideas are not force-filled.",
|
||||||
|
"crypto_light_research_seconds": 21.77,
|
||||||
|
"crypto_light_research_sources": 55,
|
||||||
|
"crypto_light_research_rejected_sources": 11,
|
||||||
|
"research_insufficient_count": 0,
|
||||||
|
"research_survivors": 6,
|
||||||
|
"protocol_security_gate_blocked": 0,
|
||||||
|
"protocol_security_gate_passed": 6,
|
||||||
|
"token_red_team_failures": {
|
||||||
|
"SPECULATION_DEPENDENT": 6,
|
||||||
|
"SLASHING_NOT_OBJECTIVE": 2,
|
||||||
|
"REVENUE_CLAIM_LANGUAGE": 4,
|
||||||
|
"BUYBACK_DEPENDENCY": 4,
|
||||||
|
"YIELD_DEPENDENCY": 4,
|
||||||
|
"SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1
|
||||||
|
},
|
||||||
|
"token_red_team_count": 6,
|
||||||
|
"sol_token_red_team_requests": 6,
|
||||||
|
"top5_deep_research_count": 5,
|
||||||
|
"top5_research_coverage_before": {
|
||||||
|
"ace6f45b-84a9-4b91-9718-f2504c9da638": 0.12,
|
||||||
|
"0b8c4fa3-febf-4646-b750-eece96fd9379": 0.12,
|
||||||
|
"9bffcfb7-01b9-4cb8-85a4-09308417930f": 0.12,
|
||||||
|
"caacd3f6-10e6-412d-90f8-167557da235b": 0.12,
|
||||||
|
"acb07824-7217-4253-a1d7-1f5122c4fd9b": 0.19
|
||||||
|
},
|
||||||
|
"top5_research_coverage_after": {
|
||||||
|
"ace6f45b-84a9-4b91-9718-f2504c9da638": 0.19,
|
||||||
|
"0b8c4fa3-febf-4646-b750-eece96fd9379": 0.19,
|
||||||
|
"9bffcfb7-01b9-4cb8-85a4-09308417930f": 0.19,
|
||||||
|
"caacd3f6-10e6-412d-90f8-167557da235b": 0.19,
|
||||||
|
"acb07824-7217-4253-a1d7-1f5122c4fd9b": 0.19
|
||||||
|
},
|
||||||
|
"crypto_ranked_count": 6,
|
||||||
|
"crypto_top_3_count": 0,
|
||||||
|
"autonomous_crypto_survivors": 0,
|
||||||
|
"assisted_high_potential": 0,
|
||||||
|
"finalists": 0,
|
||||||
|
"sol_final_ic_requests": 6,
|
||||||
|
"qwen_requests": 0,
|
||||||
|
"human_legal_gate_count": 6,
|
||||||
|
"legal_review_required": true
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Model Usage
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"sol_generation_requests": 20,
|
||||||
|
"sol_onchain_judge_requests": 20,
|
||||||
|
"sol_protocol_architecture_requests": 11,
|
||||||
|
"sol_token_design_requests": 11,
|
||||||
|
"sol_token_utility_judge_requests": 11,
|
||||||
|
"sol_final_ic_requests": 6,
|
||||||
|
"qwen_requests": 0
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Ranking
|
||||||
|
|
||||||
|
### Rank 1: PatchBond Network
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `74.9`. Token necessity: `TOKEN_STRONGLY_JUSTIFIED`.
|
||||||
|
|
||||||
|
Product thesis: Enterprise customers increasingly require proof that vendors can remediate exploitable vulnerabilities quickly, but today they rely on questionnaires, vague SLAs, and private trust. PatchBond creates standardized security performance bonds tied to specific software products, vulnerability classes, severity levels, and remediation deadlines. Vendors pay to publish bonded commitments; independent assessors verify incidents and outcomes; buyers use the bond history as procurement evidence.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can standardize definitions, evidence rules, verification workflows, and payout conditions across many vendors and buyers, making security commitments comparable and reusable.
|
||||||
|
|
||||||
|
Token thesis: PatchBond Protocol does not require a native token for its minimum viable economic design. The core system depends on enforceable bond collateral, verified attestations, claim settlement, assessor accountability, vendor performance records, and buyer/insurer data access. These functions are better served by stablecoins, fiat escrow, surety instruments, legal agreements, credentialed assessor registries, and slashing of denominated collateral. A native token would add volatility, regulatory risk, and incentive distortion unless it is strictly limited to a protocol-level security bond for participants without legal or contractual recourse.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to Enterprise security, procurement, and third-party risk teams evaluating software vendors. for Enterprise customers increasingly require proof that vendors can remediate exploitable vulnerabilities quickly, but today they rely on questionnaires, vague SLAs, and private trust. PatchBond creates standardized securit; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Subscription and transaction fees paid in fiat by vendors, buyers, and insurers.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", "PROVIDER_ADMISSION": "USEFUL", "RESOURCE_ALLOCATION": "USEFUL", "MACHINE_ECONOMIC_IDENTITY": "OPTIONAL", "CONTRIBUTION_ACCOUNTING": "USEFUL", "SECURITY_BUDGET": "OPTIONAL", "PROTOCOL_FEE_ASSET": "UNNECESSARY", "PROVIDER_REWARD": "UNNECESSARY", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "UNNECESSARY", "ACCESS": "UNNECESSARY", "TREASURY": "OPTIONAL", "OTHER": "UNNECESSARY"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: users consume service; users pay protocol fees; providers stake token; bad providers are slashed; usage-linked fees sustain rewards
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with one vertical where software supply chain risk is acute, such as healthcare SaaS. Recruit vendors that already have strong remediation practices and want sales differentiation. Run manual verification with a small assessor panel before automating intake and reporting.
|
||||||
|
|
||||||
|
Autonomous operability: `53`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `93`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 76, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 53, "SECURITY_MODEL_QUALITY": 93, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT
|
||||||
|
|
||||||
|
Validation experiment: Create a no-code registry with 10 hypothetical bond templates and sell paid pilot participation to SaaS vendors currently facing enterprise security reviews. Measure whether buyers accept PatchBond records as a substitute for custom remediation SLA negotiation.
|
||||||
|
|
||||||
|
### Rank 2: Agent Passport Clearinghouse
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `72.3`. Token necessity: `TOKEN_STRONGLY_JUSTIFIED`.
|
||||||
|
|
||||||
|
Product thesis: As AI agents begin buying services, hiring other agents, opening accounts, and acting on behalf of humans or companies, counterparties need a shared way to know which agent they are dealing with, what authority it has, whether it pays, and whether prior counterparties had good outcomes. The product is a cross-platform economic identity layer for agents: verified agent profiles, delegated authority records, transaction references, dispute history, payment reputation, and revocable credentials.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can aggregate attestations from many competing venues without forcing any one marketplace, payment company, or model provider to control the identity graph. Participants benefit because shared trust data lowers fraud, onboarding cost, and duplicated compliance work.
|
||||||
|
|
||||||
|
Token thesis: A native token is not required for the minimal protocol. The architecture's core value comes from verifiable identity, authority, attestations, reputation portability, settlement hooks, and dispute records. These functions can be performed with signed credentials, onchain registries, stablecoin or ETH escrow, application fees, and offchain commercial agreements. A native token would only become structurally justified if the protocol needs permissionless issuer/resolver/admission markets with slashable economic security that cannot be credibly supplied using external collateral.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to Companies deploying autonomous agents that transact with external vendors, marketplaces, APIs, financial services, and other agents. for As AI agents begin buying services, hiring other agents, opening accounts, and acting on behalf of humans or companies, counterparties need a shared way to know which agent they are dealing with, what authority it has, w; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Monthly SaaS subscription plus usage-based API pricing.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", "PROVIDER_ADMISSION": "USEFUL", "RESOURCE_ALLOCATION": "OPTIONAL", "MACHINE_ECONOMIC_IDENTITY": "USEFUL", "CONTRIBUTION_ACCOUNTING": "OPTIONAL", "SECURITY_BUDGET": "OPTIONAL", "PROTOCOL_FEE_ASSET": "UNNECESSARY", "PROVIDER_REWARD": "UNNECESSARY", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "UNNECESSARY", "ACCESS": "UNNECESSARY", "TREASURY": "UNNECESSARY", "OTHER": "UNNECESSARY"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: {'loop': 'Permissionless trust provider loop', 'description': 'More counterparties rely on attestations and dispute outcomes, which increases the value of honest issuers and resolvers. If those providers must post slashable collateral, demand for the collateral asset rises with protocol trust volume.', 'requires_native_token': False, 'preferred_asset': 'stablecoin, ETH, or other high-liquidity collateral'}; {'loop': 'Agent bond loop', 'description': 'Higher-risk or higher-volume agents may need larger bonds to receive better limits, acceptance, or pricing. Bond demand grows with transaction volume and counterparty risk tolerance.', 'requires_native_token': False, 'preferred_asset': 'stablecoin or escrowed settlement asset'}; {'loop': 'Resolver accountability loop', 'description': 'Dispute resolvers that handle more value may need larger slashing bonds. Incorrect, biased, or fraudulent outcomes can be penalized, improving confidence in dispute attestations.', 'requires_native_token': False, 'preferred_asset': 'stablecoin, ETH, or insurance-backed collateral'}
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with a narrow wedge: verified economic identity for agents transacting in one high-value category such as API resale, freelance agent services, or automated procurement. Manually onboard early issuers and counterparties, build trust records from real transactions, then expose APIs once repeated verification requests emerge.
|
||||||
|
|
||||||
|
Autonomous operability: `64`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `85`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 84, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 82.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 64, "SECURITY_MODEL_QUALITY": 85, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT; SLASHING_NOT_OBJECTIVE
|
||||||
|
|
||||||
|
Validation experiment: Partner with one agent marketplace or API platform and manually verify 50 agents. Measure whether verified passports increase counterparty acceptance, reduce onboarding time, reduce fraud incidents, or improve payment completion versus unverified agents.
|
||||||
|
|
||||||
|
### Rank 3: Compute Clearance Network
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `63.7`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||||
|
|
||||||
|
Product thesis: As more infrastructure becomes autonomous, buyers will need capacity that is not just available, but provably reachable, correctly configured, and able to meet latency, uptime, location, and security constraints. Compute Clearance Network would act as a neutral coordination layer where independent operators list machine capacity, automated buyers express service requirements, and the network matches, monitors, and settles usage based on observed performance.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can standardize supply descriptions, independent monitoring, reputation, workload placement, failover routing, and commercial settlement without forcing all participants into one cloud, one hardware vendor, or one application stack.
|
||||||
|
|
||||||
|
Token thesis: A native token is minimally justified only if it is the protocol's slashable economic security asset for provider, verifier, solver, and machine-agent accountability. It should not be required as the primary payment asset, governance token, access credential, or generic reward asset. The strongest use is staking/bonding against objectively verifiable service commitments, capacity claims, verifier accuracy, and failover obligations where the protocol needs a common collateral unit that can be escrowed, slashed, and reputation-linked across heterogeneous providers and jurisdictions.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to Infrastructure teams, robotics operators, edge AI companies, autonomous vehicle fleets, industrial automation providers, and machine agents that need reliable distributed compute o for As more infrastructure becomes autonomous, buyers will need capacity that is not just available, but provably reachable, correctly configured, and able to meet latency, uptime, location, and security constraints. Compute; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Fiat subscription, card, ACH, wire transfer, and usage-based invoicing.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", "PROVIDER_ADMISSION": "STRONGLY_USEFUL", "RESOURCE_ALLOCATION": "STRONGLY_USEFUL", "MACHINE_ECONOMIC_IDENTITY": "STRONGLY_USEFUL", "CONTRIBUTION_ACCOUNTING": "USEFUL", "SECURITY_BUDGET": "STRONGLY_USEFUL", "PROTOCOL_FEE_ASSET": "OPTIONAL", "PROVIDER_REWARD": "OPTIONAL", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "OPTIONAL", "ACCESS": "UNNECESSARY", "TREASURY": "OPTIONAL", "OTHER": "USEFUL"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: {'loop': 'More buyer demand creates more active service commitments; more commitments require larger provider bonds; larger bonded demand creates structural token lockup proportional to economic risk.'}; {'loop': 'Higher-value workloads require stronger verification; verifier and monitor roles must post accuracy bonds; verifier bond demand rises with settlement volume and dispute value.'}; {'loop': 'Providers with better reputation can win more demand but must maintain sufficient bonded collateral; reputation and earning capacity become linked to continued token staking.'}; {'loop': 'Solvers routing larger or more complex commitments post bonds against manipulation, failed routing, or invalid reservation proposals; solver bond demand grows with routing volume.'}; {'loop': 'Slashing events recapitalize insurance, verifier rewards, or buyer compensation pools, increasing trust in the network and allowing higher-value demand to enter.'}; {'loop': 'As autonomous machine agents use the protocol, bonded machine identities accumulate reputation, increasing switching costs and making the token a persistent accountability layer.'}
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with one narrow wedge: regional GPU and edge CPU capacity for latency-sensitive inference failover. Recruit operators with underutilized hardware, validate their capacity through active probes, and sell redundancy packages to AI application teams already worried about cloud outages or regional latency.
|
||||||
|
|
||||||
|
Autonomous operability: `52`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `85`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 100, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 72.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 52, "SECURITY_MODEL_QUALITY": 85, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT; REVENUE_CLAIM_LANGUAGE; BUYBACK_DEPENDENCY; YIELD_DEPENDENCY
|
||||||
|
|
||||||
|
Validation experiment: Within 30 days, onboard at least 3 independent providers in different regions, run synthetic workloads every hour, sell one paid failover pilot to an inference customer, and prove that the network can route traffic away from a degraded provider within a defined recovery window.
|
||||||
|
|
||||||
|
### Rank 4: ProofGrid Compute Attestation Network
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `62.9`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||||
|
|
||||||
|
Product thesis: As AI teams increasingly use fragmented third-party GPU capacity, they need a way to trust that contributed compute was actually performed on the claimed hardware, produced reproducible outputs, and met job-level quality requirements. ProofGrid provides job orchestration, hardware attestation, benchmarked performance records, reproducibility checks, and payment settlement for independent compute contributors.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can standardize hardware proofs, job attestations, benchmark records, dispute evidence, and provider reputation across many marketplaces instead of locking trust data inside one compute platform.
|
||||||
|
|
||||||
|
Token thesis: A native token is not strictly required for ProofGrid's core marketplace, payment, governance, rewards, or access functions. The minimum defensible native-token role exists only if ProofGrid needs a shared, slashable security bond that creates machine-level economic accountability across marketplaces, providers, verifiers, and dispute domains. The token should not be the default payment asset or governance asset. Its strongest possible function is protocol-native collateral for fraud deterrence, verifier accountability, provider admission, and portable economic identity.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `65.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to AI labs, inference platforms, synthetic data companies, rendering pipelines, and research teams that need burst GPU capacity but cannot rely solely on hyperscalers or opaque spot m for As AI teams increasingly use fragmented third-party GPU capacity, they need a way to trust that contributed compute was actually performed on the claimed hardware, produced reproducible outputs, and met job-level quality; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Fiat payments by invoice, ACH, wire, or credit card; supplier payouts through standard fiat payment rails.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "REQUIRED", "PROVIDER_ADMISSION": "STRONGLY_USEFUL", "RESOURCE_ALLOCATION": "USEFUL", "MACHINE_ECONOMIC_IDENTITY": "STRONGLY_USEFUL", "CONTRIBUTION_ACCOUNTING": "USEFUL", "SECURITY_BUDGET": "USEFUL", "PROTOCOL_FEE_ASSET": "UNNECESSARY", "PROVIDER_REWARD": "OPTIONAL", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "OPTIONAL", "ACCESS": "UNNECESSARY", "TREASURY": "OPTIONAL", "OTHER": "UNNECESSARY"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: {'loop': 'Provider bond demand', 'steps': ['Providers need bonded status to access higher-value jobs.', 'Higher bonded capacity enables larger job limits and better routing eligibility.', 'Fraud or SLA failure can slash bonded collateral.', 'Reliable providers retain bonds and earn more compute revenue.']}; {'loop': 'Verifier bond demand', 'steps': ['Verifiers bond before issuing attestations that affect settlement.', 'Accurate attestations earn fees.', 'False, lazy, or collusive attestations are slashable.', 'High-quality verifiers gain higher assignment probability.']}; {'loop': 'Machine identity demand', 'steps': ['Hardware profiles become economically meaningful only when backed by slashable stake.', 'More valuable machines or clusters require larger bonds.', 'Reputation and bond history travel across marketplaces.', 'Buyers trust portable bonded records more than isolated marketplace ratings.']}; {'loop': 'Risk-tier demand', 'steps': ['Sensitive, expensive, or hard-to-reproduce workloads require stronger collateral.', 'Providers increase bonded exposure to qualify for premium work.', 'Premium jobs produce higher provider revenue and protocol fees.', 'The network security budget increases with verified compute demand.']}
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with one narrow workload category such as batch LLM inference or synthetic data generation. Recruit 5 to 10 GPU suppliers with known hardware. Build a lightweight attestation and benchmark agent. Run paid pilots with 2 to 3 AI startups. Publish reliability and cost comparisons against cloud spot pricing.
|
||||||
|
|
||||||
|
Autonomous operability: `52`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `85`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 100, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 52, "SECURITY_MODEL_QUALITY": 85, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 65.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT; REVENUE_CLAIM_LANGUAGE; BUYBACK_DEPENDENCY; YIELD_DEPENDENCY
|
||||||
|
|
||||||
|
Validation experiment: Within 30 days, onboard at least 20 GPUs from 3 independent suppliers, route 10,000 real inference jobs from one paying customer, verify hardware claims and output reproducibility on sampled jobs, and demonstrate at least 20% cost savings versus the customer’s baseline cloud option.
|
||||||
|
|
||||||
|
### Rank 5: ProofBond
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `60.5`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||||
|
|
||||||
|
Product thesis: As AI agents, robots, inference endpoints, and automated services transact with limited human supervision, buyers need a way to know which machines can be trusted before assigning work. ProofBond creates a shared reputation layer where machine operators attach economic guarantees to specific capabilities, independent verifiers measure performance, and counterparties can route work based on bonded track records rather than platform-owned reviews.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can aggregate machine performance across many customers without being controlled by any one marketplace, making reputation portable, harder to manipulate, and more valuable to both buyers and operators.
|
||||||
|
|
||||||
|
Token thesis: A native token is justified only if ProofBond needs a protocol-native, slashable assurance asset that binds machine identities, capability claims, verifier behavior, and settlement security across otherwise fragmented marketplaces. The strongest utility is not payment, governance, access, or rewards. It is a common cryptoeconomic security primitive: stake that can be locked, risk-weighted, slashed, routed, and reputation-linked across machine claims and verifier attestations. If ProofBond can use stablecoins or external collateral for all bonds without weakening security, then a native token is unnecessary.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to Businesses that procure work from autonomous machines or AI agents and need measurable assurance before delegating valuable tasks. for As AI agents, robots, inference endpoints, and automated services transact with limited human supervision, buyers need a way to know which machines can be trusted before assigning work. ProofBond creates a shared reputat; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Fiat subscription, card, ACH, wire transfer, and usage-based API billing.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", "PROVIDER_ADMISSION": "STRONGLY_USEFUL", "RESOURCE_ALLOCATION": "STRONGLY_USEFUL", "MACHINE_ECONOMIC_IDENTITY": "REQUIRED", "CONTRIBUTION_ACCOUNTING": "USEFUL", "SECURITY_BUDGET": "STRONGLY_USEFUL", "PROTOCOL_FEE_ASSET": "OPTIONAL", "PROVIDER_REWARD": "OPTIONAL", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "OPTIONAL", "ACCESS": "UNNECESSARY", "TREASURY": "OPTIONAL", "OTHER": "USEFUL"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: Machine operators need token to bond capability claims and qualify for higher-value buyer routing.; Higher-value tasks require larger or higher-quality bonds, increasing demand for locked token.; Verifiers and dispute reviewers stake token to gain assignment rights and credibility.; Fraud, bad attestations, or failed bonded claims cause slashing, making reputation costly to fake.; Reliable machines accumulate stronger reputation, receive more demand, and justify larger active bonds.; Protocol fees from bond origination, settlement, verification, API access, and disputes can support the security budget.; As more buyers rely on ProofBond reputation, operators and verifiers need more bonded economic identity, increasing token lock demand.
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with one narrow category such as AI compliance review agents. Recruit 20 operators, manually verify their claims, sell access to 5 buyer design partners, and publish a lightweight reputation API that procurement and workflow platforms can integrate.
|
||||||
|
|
||||||
|
Autonomous operability: `54`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `85`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 100, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 54, "SECURITY_MODEL_QUALITY": 85, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT; REVENUE_CLAIM_LANGUAGE; BUYBACK_DEPENDENCY; YIELD_DEPENDENCY; SLASHING_NOT_OBJECTIVE
|
||||||
|
|
||||||
|
Validation experiment: Run a 30-day pilot where buyers compare vendor selection using ProofBond profiles against their normal diligence process. Measure reduction in evaluation time, buyer willingness to pay, operator willingness to post commercial guarantees, and whether verified profiles increase conversion rates.
|
||||||
|
|
||||||
|
### Rank 6: ProofGrid Compute Escrow
|
||||||
|
|
||||||
|
Decision: `REJECT_SPECULATIVE`. Score: `58.6`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||||
|
|
||||||
|
Product thesis: Decentralized AI compute markets fail when buyers cannot verify whether a remote GPU provider actually ran the requested workload correctly, completely, and privately. ProofGrid provides a pre-token SaaS and coordination layer that standardizes job packaging, execution attestations, redundancy checks, output verification, escrow release, and supplier reputation across independent GPU hosts.
|
||||||
|
|
||||||
|
Protocol thesis: A neutral network can let multiple marketplaces, GPU hosts, and buyers use the same verification, escrow, and reputation layer without forcing all liquidity into one vertically integrated compute marketplace.
|
||||||
|
|
||||||
|
Token thesis: ProofGrid does not structurally require a native token for payments, escrow, rewards, governance, or access. Stablecoins can handle buyer payments, supplier payouts, verifier fees, dispute fees, and collateral. A native token is only justified if the protocol needs a shared slashable security asset that binds suppliers, verifiers, reviewers, and machine identities to long-lived economic accountability across marketplaces. The minimum defensible token role is therefore not money, governance, or fee capture, but a protocol-wide security bond used for admission, slashing, reputation weighting, and security-budget formation.
|
||||||
|
|
||||||
|
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, service credits, or legally reviewed membership. No native token required.
|
||||||
|
|
||||||
|
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "Sell 10 x $100 paid beta/API-credit packages to AI teams, model-serving startups, research labs, and inference platforms buying burst or spot GPU capacity outside hyperscalers. for Decentralized AI compute markets fail when buyers cannot verify whether a remote GPU provider actually ran the requested workload correctly, completely, and privately. ProofGrid provides a pre-token SaaS and coordination; fulfill with hosted testnet/API access and automated reports.", "5000": "Sell 20 x $250 monthly usage-credit packages via Fiat invoices, credit card, ACH, wire transfer, and stablecoin payment rails where legally supported.; buyers get measurable protocol simulations, SDK/API access, and evidence dashboards before any token.", "10000": "Sell 20 x $500 subscription/service-credit plans; fulfillment is self-service onboarding, usage metering, testnet jobs, and downloadable verification evidence."}
|
||||||
|
|
||||||
|
Token role decomposition: {"SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", "PROVIDER_ADMISSION": "USEFUL", "RESOURCE_ALLOCATION": "OPTIONAL", "MACHINE_ECONOMIC_IDENTITY": "USEFUL", "CONTRIBUTION_ACCOUNTING": "USEFUL", "SECURITY_BUDGET": "STRONGLY_USEFUL", "PROTOCOL_FEE_ASSET": "UNNECESSARY", "PROVIDER_REWARD": "UNNECESSARY", "DEMAND_SIDE_PAYMENT": "UNNECESSARY", "GOVERNANCE": "OPTIONAL", "ACCESS": "UNNECESSARY", "TREASURY": "OPTIONAL", "OTHER": "UNNECESSARY"}
|
||||||
|
|
||||||
|
Stablecoin counterfactual: {"MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", "MODEL_C_stablecoin_payment_stablecoin_collateral": "valid if slashing/collateral does not need protocol-native exposure", "MODEL_D_onchain_no_proprietary_token": "valid if proprietary token adds no security/resource allocation advantage", "MODEL_E_centralized_saas_database": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "external_collateral_identical_security": false, "stable_collateral_identical_security": false}
|
||||||
|
|
||||||
|
External collateral counterfactual: {}
|
||||||
|
|
||||||
|
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||||
|
|
||||||
|
Token demand loop: {'loop': 'bonded trust loop', 'steps': ['suppliers bond token to access higher-value jobs', 'bonded suppliers build portable reputation through successful settlements', 'higher reputation reduces verification burden and increases routing priority', 'more job flow increases the value of maintaining bonded status', 'fraud or non-performance burns reputation and can slash bonded token']}; {'loop': 'verification security loop', 'steps': ['verifiers bond token to receive verification assignments', 'accurate verification earns stablecoin fees and reputation', 'incorrect or malicious verification risks slashing', 'higher verifier reliability allows the protocol to secure larger escrow volumes', 'larger escrow volume increases demand for credible bonded verifier capacity']}; {'loop': 'machine identity loop', 'steps': ['hardware identities are linked to bonded supplier accounts', 'machines accumulate reliability history', 'abandoning or replacing a poor identity becomes economically costly', 'buyers and orchestrators route more work to machines with credible bonded histories']}; {'loop': 'security budget loop', 'steps': ['slashing and optional protocol fees fund verification, audits, and dispute infrastructure', 'better security reduces buyer loss from failed or fraudulent jobs', 'higher buyer confidence increases escrow volume', 'higher escrow volume increases demand for bonded suppliers and verifiers']}
|
||||||
|
|
||||||
|
Value capture: Usage fees accrue to providers, security budget, and protocol treasury.
|
||||||
|
|
||||||
|
Network effect: More users attract more providers, improving liquidity/reliability.
|
||||||
|
|
||||||
|
Bootstrap plan: Start with batch inference and evaluation workloads where deterministic or statistically verifiable outputs are practical. Partner with 3 to 5 GPU suppliers and 5 AI teams that already buy off-cloud compute. Build a lightweight SDK, escrow dashboard, supplier onboarding flow, and verification policy engine. Use manual dispute review initially while automating the highest-frequency checks.
|
||||||
|
|
||||||
|
Autonomous operability: `42`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `PASS_FOR_TESTNET_DESIGN`. Security risk score: `85`.
|
||||||
|
|
||||||
|
Scores: {"TOKEN_NECESSITY": 88, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 82.0, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 55, "AUTONOMOUS_OPERABILITY": 42, "SECURITY_MODEL_QUALITY": 85, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||||
|
|
||||||
|
Token Red Team flags: SPECULATION_DEPENDENT; REVENUE_CLAIM_LANGUAGE; BUYBACK_DEPENDENCY; YIELD_DEPENDENCY; SLASHING_DEPENDS_ON_HUMAN_JUDGMENT
|
||||||
|
|
||||||
|
Validation experiment: Run 100 paid jobs across at least 5 independent GPU suppliers, intentionally inject supplier failures or degraded execution in a controlled subset, and measure whether the system detects failures, prevents incorrect payment release, and gives buyers enough confidence to route repeat spend through the platform.
|
||||||
|
|
||||||
|
## Top 3
|
||||||
|
|
||||||
|
Fewer than 3 qualified; weak token ideas were not promoted.
|
||||||
|
|
||||||
|
## Routed To SaaS
|
||||||
|
|
||||||
|
- MachineProof Exchange: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- AgentTenderNet: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- PatchBourse: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- ProofLedger: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- CivicSignal Data Cooperative: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- ModelPatch Commons: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- GridForge Flex Market: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- BurstCache Exchange: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
- CareRoute Neutral Coordination Network: `None`
|
||||||
|
Failed onchain/token counterfactual but may be valuable as pre-token/SaaS product.
|
||||||
|
|
||||||
|
## V0.2 Comparison
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"v02": {
|
||||||
|
"raw": 30,
|
||||||
|
"crypto_survivors": 2,
|
||||||
|
"autonomous_survivors": 0,
|
||||||
|
"finalists": 0
|
||||||
|
},
|
||||||
|
"v03": {
|
||||||
|
"raw": 20,
|
||||||
|
"onchain_rejected": 5,
|
||||||
|
"onchain_passed": 15,
|
||||||
|
"token_unnecessary": 12,
|
||||||
|
"token_optional": 3,
|
||||||
|
"crypto_survivors": 0,
|
||||||
|
"finalists": 0
|
||||||
|
},
|
||||||
|
"v031": {
|
||||||
|
"raw": 20,
|
||||||
|
"onchain_passed": 11,
|
||||||
|
"onchain_rejected": 9,
|
||||||
|
"token_strongly_justified": 1,
|
||||||
|
"token_essential": 5,
|
||||||
|
"crypto_survivors": 6,
|
||||||
|
"autonomous_survivors": 0,
|
||||||
|
"assisted_high_potential": 0,
|
||||||
|
"finalists": 0,
|
||||||
|
"average_research_quality": 0.18,
|
||||||
|
"idea_diversity": {
|
||||||
|
"protocol_category_distribution": {
|
||||||
|
"PatchBond": 1,
|
||||||
|
"Agent": 1,
|
||||||
|
"Compute": 1,
|
||||||
|
"ProofGrid": 2,
|
||||||
|
"ProofBond": 1
|
||||||
|
},
|
||||||
|
"token_utility_distribution": {
|
||||||
|
"token utility not proven": 1,
|
||||||
|
"decentralized marketplace coordination": 4,
|
||||||
|
"proof/attestation markets": 2,
|
||||||
|
"protocol fee settlement": 1
|
||||||
|
},
|
||||||
|
"saturation_flags": []
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Token Red Team Failures
|
||||||
|
|
||||||
|
{
|
||||||
|
"SPECULATION_DEPENDENT": 6,
|
||||||
|
"SLASHING_NOT_OBJECTIVE": 2,
|
||||||
|
"REVENUE_CLAIM_LANGUAGE": 4,
|
||||||
|
"BUYBACK_DEPENDENCY": 4,
|
||||||
|
"YIELD_DEPENDENCY": 4,
|
||||||
|
"SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1
|
||||||
|
}
|
||||||
|
|
||||||
|
## Research Health
|
||||||
|
|
||||||
|
{
|
||||||
|
"search_engines": {
|
||||||
|
"RATE_LIMITED": 30,
|
||||||
|
"ACCESS_DENIED": 18,
|
||||||
|
"CAPTCHA": 30,
|
||||||
|
"TIMEOUT": 5,
|
||||||
|
"PROTOCOL_ERROR": 2
|
||||||
|
},
|
||||||
|
"sources_accepted": 71,
|
||||||
|
"sources_rejected": 5,
|
||||||
|
"primary_sources_accepted": 55,
|
||||||
|
"queries_avoided_due_to_circuit_breaker": 150,
|
||||||
|
"average_coverage": 0.18,
|
||||||
|
"healthy": 0,
|
||||||
|
"rate_limited": 30,
|
||||||
|
"captcha": 30,
|
||||||
|
"denied": 18,
|
||||||
|
"timed_out": 5
|
||||||
|
}
|
||||||
|
|
||||||
|
## Token Utility Distribution
|
||||||
|
|
||||||
|
{
|
||||||
|
"token utility not proven": 1,
|
||||||
|
"decentralized marketplace coordination": 4,
|
||||||
|
"proof/attestation markets": 2,
|
||||||
|
"protocol fee settlement": 1
|
||||||
|
}
|
||||||
|
|
||||||
|
## Capability Gaps
|
||||||
|
|
||||||
|
[
|
||||||
|
{
|
||||||
|
"capability": "Guard model",
|
||||||
|
"count": 6,
|
||||||
|
"status": "AVAILABLE",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "protocol threat modelling",
|
||||||
|
"count": 6,
|
||||||
|
"status": "AVAILABLE",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "Solidity implementation",
|
||||||
|
"count": 6,
|
||||||
|
"status": "AVAILABLE",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "token simulation harness",
|
||||||
|
"count": 6,
|
||||||
|
"status": "AVAILABLE",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "crypto research workflow",
|
||||||
|
"count": 6,
|
||||||
|
"status": "PARTIAL",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "testnet deployment",
|
||||||
|
"count": 6,
|
||||||
|
"status": "PARTIAL",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "wallet auth",
|
||||||
|
"count": 6,
|
||||||
|
"status": "MISSING",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "key management",
|
||||||
|
"count": 6,
|
||||||
|
"status": "MISSING",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "contract deployment pipeline",
|
||||||
|
"count": 6,
|
||||||
|
"status": "MISSING",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "oracle/provider monitoring",
|
||||||
|
"count": 6,
|
||||||
|
"status": "MISSING",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"capability": "legal review workflow",
|
||||||
|
"count": 6,
|
||||||
|
"status": "MISSING",
|
||||||
|
"earliest_stage": "BEFORE_VALIDATION"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
|
||||||
|
Stop condition: no token sale, no NFT sale, no Founding Membership sale, no fundraising, no mainnet issuance, no investor/user contact, no liquidity pool, no market making, no real spend.
|
||||||
Loading…
Add table
Reference in a new issue