Add crypto protocol cohort V0.2 export
This commit is contained in:
parent
3cdd7b0cae
commit
783ad66f4e
4 changed files with 7271 additions and 2 deletions
|
|
@ -11,7 +11,7 @@ from control_plane.ventures.models import VentureCohort
|
|||
|
||||
|
||||
class Command(BaseCommand):
|
||||
help = "Export a Crypto Venture Cohort V0.1 report."
|
||||
help = "Export a Crypto Venture Cohort V0.2 report."
|
||||
|
||||
def add_arguments(self, parser):
|
||||
parser.add_argument("--cohort", help="Cohort stable ID or primary key. Defaults to latest crypto cohort.")
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ from model_router.router import ModelRouter
|
|||
|
||||
|
||||
class Command(BaseCommand):
|
||||
help = "Run a Crypto / Protocol Venture Cohort V0.1."
|
||||
help = "Run a Crypto / Protocol Venture Cohort V0.2."
|
||||
|
||||
def add_arguments(self, parser):
|
||||
parser.add_argument("--size", type=int, default=30)
|
||||
|
|
|
|||
7011
docs/crypto_venture_cohort_v02_20260816.json
Normal file
7011
docs/crypto_venture_cohort_v02_20260816.json
Normal file
File diff suppressed because one or more lines are too long
258
docs/crypto_venture_cohort_v02_20260816.md
Normal file
258
docs/crypto_venture_cohort_v02_20260816.md
Normal file
|
|
@ -0,0 +1,258 @@
|
|||
# CRYPTO VENTURE COHORT V0.2
|
||||
|
||||
Cohort ID: `CPV02-20260816193138-475124fa`
|
||||
GraphRun: `8`
|
||||
Raw protocols generated: `30`
|
||||
Token unnecessary: `14`. Token optional/routed SaaS: `14`. Duplicates: `0`.
|
||||
Crypto survivors: `2`. Autonomous crypto survivors: `0`. Security-blocked: `0`. Finalists: `0`.
|
||||
Generation attempts: `30`
|
||||
|
||||
## Runtime
|
||||
|
||||
```json
|
||||
{
|
||||
"raw_target": 30,
|
||||
"raw_generated": 30,
|
||||
"requested_protocol_count": 30,
|
||||
"generation_attempts": 30,
|
||||
"accepted_protocols": 30,
|
||||
"duplicate_rejections": 0,
|
||||
"token_necessity_rejections": 0,
|
||||
"generation_sources": [
|
||||
"qwen"
|
||||
],
|
||||
"token_unnecessary_rejections": 14,
|
||||
"token_optional_route_to_saas": 14,
|
||||
"crypto_survivors": 2,
|
||||
"crypto_novelty_removed": 0,
|
||||
"hard_exclusion_rejections": 0,
|
||||
"regeneration_attempts": 0,
|
||||
"regenerated_protocols": 0,
|
||||
"unfilled_slots_after_regeneration": 28,
|
||||
"regeneration_policy": "V0.2 uses total raw generation budget; weak token ideas are not force-filled.",
|
||||
"crypto_light_research_seconds": 116.6,
|
||||
"crypto_light_research_sources": 25,
|
||||
"crypto_light_research_rejected_sources": 80,
|
||||
"research_insufficient_count": 0,
|
||||
"research_survivors": 2,
|
||||
"protocol_security_gate_blocked": 0,
|
||||
"protocol_security_gate_passed": 2,
|
||||
"token_red_team_failures": {
|
||||
"TOKEN_DOES_TOO_MUCH": 2,
|
||||
"NATIVE_PAYMENT_NOT_REQUIRED": 2,
|
||||
"REVENUE_CLAIM_LANGUAGE": 1,
|
||||
"BUYBACK_DEPENDENCY": 1,
|
||||
"YIELD_DEPENDENCY": 1
|
||||
},
|
||||
"top5_deep_research_count": 2,
|
||||
"top5_research_coverage_before": {
|
||||
"b31ddbf7-5440-4b0b-b092-19c62c0a34ca": 0.33,
|
||||
"4e9100af-5479-4dcb-a9df-b549c6de02a4": 0.33
|
||||
},
|
||||
"top5_research_coverage_after": {
|
||||
"b31ddbf7-5440-4b0b-b092-19c62c0a34ca": 0.4,
|
||||
"4e9100af-5479-4dcb-a9df-b549c6de02a4": 0.47
|
||||
},
|
||||
"crypto_ranked_count": 2,
|
||||
"crypto_top_3_count": 0,
|
||||
"autonomous_crypto_survivors": 0,
|
||||
"finalists": 0,
|
||||
"human_legal_gate_count": 2,
|
||||
"legal_review_required": true
|
||||
}
|
||||
```
|
||||
|
||||
## Ranking
|
||||
|
||||
### Rank 1: VeriMesh
|
||||
|
||||
Decision: `ROUTE_TO_SAAS`. Score: `64.0`. Token necessity: `TOKEN_OPTIONAL`.
|
||||
|
||||
Product thesis: VeriMesh provides a 'Proof of Execution' primitive where autonomous agents (bots, AI agents, or microservices) submit cryptographic proofs of their work (e.g., data processing, rendering, inference) to a decentralized validator set. The product is a lightweight SDK and a set of smart contracts that allow any dApp to query an agent's historical reliability score and verify specific task outputs in real-time.
|
||||
|
||||
Protocol thesis: Current Web3 relies on centralized APIs or trusted oracles for off-chain data/computation. VeriMesh creates a market for 'reputation capital' by allowing agents to stake a bond against their work. If the work is verified as correct by a decentralized proof-of-work/proof-of-stake hybrid validator network, the agent earns reputation points and fees. If the work is malicious or faulty, the bond is slashed. This creates a self-correcting, trustless marketplace for machine labor.
|
||||
|
||||
Token thesis: The VERI token is the unit of account for the protocol. It is used to stake bonds for agents, pay for verification services, and reward validators. It is not a security or a utility token for a SaaS product, but the native medium of exchange and collateral for the reputation market.
|
||||
|
||||
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, or legally reviewed membership. No native token required.
|
||||
|
||||
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `80.0`. Revenue ladder: {"1000": "sell small paid beta/API-credit packages", "5000": "10-25 paid beta users or usage-credit customers", "10000": "recurring API/subscription/service-credit revenue without native token"}
|
||||
|
||||
Token role decomposition: {"PAYMENT": "USEFUL", "SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", "GOVERNANCE": "USEFUL", "RESOURCE_ACCESS": "USEFUL", "REPUTATION": "REQUIRED", "REWARD": "USEFUL", "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_centralized_database_credits": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "stable_collateral_identical_security": false}
|
||||
|
||||
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||
|
||||
Token demand loop: Agents must hold VERI to stake bonds, creating baseline demand.; Validators must stake VERI to participate in verification, locking up supply.; Slashing events burn a portion of the staked VERI, reducing supply over time as the network matures and errors are penalized.; As more dApps integrate VeriMesh, the volume of tasks increases, driving higher demand for verification services and thus more VERI circulation.
|
||||
|
||||
Value capture: The protocol captures value through a small fee (e.g., 2%) on every successful task transaction, which is distributed to validators and burned. Additionally, the protocol benefits from the appreciation of the VERI token as the network's reputation data becomes more valuable and trusted.
|
||||
|
||||
Network effect: More agents join to access the reputation market, which attracts more dApps seeking reliable computation. More dApps mean more tasks, which attracts more validators to secure the network. A larger validator set increases the security and reliability of the reputation scores, making the network more attractive to high-value agents.
|
||||
|
||||
Bootstrap plan: 1. Deploy smart contracts on a testnet (e.g., Sepolia) with a simulated VERI token. 2. Develop the SDK and reference implementation for a simple task (e.g., hash computation). 3. Recruit a small group of 'pioneer' agents and validators to run a closed beta on the testnet. 4. Use fake credits to simulate economic incentives and validate the slashing/reward logic. 5. Publish a whitepaper and open-source the codebase to attract community interest.
|
||||
|
||||
Autonomous operability: `42`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `REVISE_SECURITY_MODEL`. Security risk score: `69`.
|
||||
|
||||
Scores: {"TOKEN_NECESSITY": 35.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 91, "VALUE_ACCRUAL_QUALITY": 86, "NETWORK_EFFECT_POTENTIAL": 65, "TOKENOMICS_SUSTAINABILITY": 94, "BOOTSTRAPPABILITY": 78, "AUTONOMOUS_OPERABILITY": 42, "SECURITY_MODEL_QUALITY": 69, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 80.0}
|
||||
|
||||
Token Red Team flags: TOKEN_DOES_TOO_MUCH; NATIVE_PAYMENT_NOT_REQUIRED
|
||||
|
||||
Validation experiment: Run a 4-week simulation on a local testnet with 10 simulated agents and 5 validators. Introduce 20% 'malicious' agents that submit incorrect proofs. Measure the time to detection, the accuracy of slashing, and the economic impact on the validator set. Success is defined as 95% detection of malicious work within 10 blocks and no false positives on valid work.
|
||||
|
||||
### Rank 2: VeriChain Attestation Exchange
|
||||
|
||||
Decision: `ROUTE_TO_SAAS`. Score: `51.5`. Token necessity: `TOKEN_OPTIONAL`.
|
||||
|
||||
Product thesis: The product is a smart contract framework that allows data producers (e.g., IoT sensor networks, supply chain logs) to request attestations from a pool of specialized validators. Validators commit to verifying specific data points (e.g., 'temperature did not exceed 40C') and stake a bond. If the data is later proven false via oracle dispute or consensus, the validator is slashed. If true, they earn fees. This creates a financial incentive for high-fidelity, low-latency real-world data verification.
|
||||
|
||||
Protocol thesis: Current oracle solutions are either centralized (Chainlink nodes) or rely on simple majority voting which is vulnerable to collusion. VeriChain introduces a 'Proof of Attestation' mechanism where validators must provide cryptographic proofs of their data collection process (e.g., signed sensor logs) before submitting the final value. Disputes are resolved via a decentralized court of expert validators who review the raw evidence. This shifts trust from 'who is the oracle' to 'what is the evidence'.
|
||||
|
||||
Token thesis: The VERI token is the native asset used for staking, fee payment, and governance. It represents a claim on the protocol's revenue and a security bond for validators. The token's value is derived from the demand for verified data and the risk-adjusted yield earned by stakers.
|
||||
|
||||
Pre-token business: Sell useful product/network access before native token issuance using fiat/stablecoin credits, paid beta, subscription, or legally reviewed membership. No native token required.
|
||||
|
||||
Pre-token monetization: `STABLECOIN_USAGE_FEES`. Potential: `70.0`. Revenue ladder: {"1000": "sell small paid beta/API-credit packages", "5000": "10-25 paid beta users or usage-credit customers", "10000": "recurring API/subscription/service-credit revenue without native token"}
|
||||
|
||||
Token role decomposition: {"PAYMENT": "USEFUL", "SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", "GOVERNANCE": "USEFUL", "RESOURCE_ACCESS": "UNNECESSARY", "REPUTATION": "REQUIRED", "REWARD": "UNNECESSARY", "TREASURY": "USEFUL", "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_centralized_database_credits": "routes to SaaS if verification/settlement/reputation do not degrade", "usdc_identical_payment_utility": true, "stable_collateral_identical_security": false}
|
||||
|
||||
Native token removed outcome: Native token removal materially degrades security/reputation if required roles remain.
|
||||
|
||||
Token demand loop: Data producers need VERI to pay for attestations, creating direct demand.; Validators must acquire and stake VERI to earn fees, creating buy pressure.; As more high-value real-world data is verified, the protocol's revenue grows, increasing the yield for stakers and attracting more capital.; Dispute resolution requires VERI to post bonds, creating additional demand during contentious events.
|
||||
|
||||
Value capture: The protocol captures value through a 10% fee on all attestation transactions, which is distributed to the protocol treasury (burned or used for buybacks) and to the validator set. The treasury accumulates VERI, which can be used to incentivize new validators or fund development, creating a flywheel of value accrual to the token.
|
||||
|
||||
Network effect: More validators lead to higher data quality and lower fees, attracting more data producers. More data producers lead to higher fees, attracting more validators. The reputation system creates a barrier to entry for low-quality validators, reinforcing the network's trustworthiness.
|
||||
|
||||
Bootstrap plan: 1. Deploy smart contracts on a testnet with a simulated VERI token. 2. Recruit 50-100 expert validators (data scientists, auditors) to stake fake credits. 3. Partner with 5-10 DeFi protocols to pilot weather and supply chain data verification. 4. Run a 3-month validation period where disputes are resolved manually by a core team to calibrate the slashing parameters. 5. Transition to a mainnet deployment with a limited set of trusted validators and a small initial liquidity pool.
|
||||
|
||||
Autonomous operability: `34`. Autonomy class: `ASSISTED_CRYPTO`. Regulatory manageability: `72`. Security: `REVISE_SECURITY_MODEL`. Security risk score: `77`.
|
||||
|
||||
Scores: {"TOKEN_NECESSITY": 32.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 83, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 65, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 78, "AUTONOMOUS_OPERABILITY": 34, "SECURITY_MODEL_QUALITY": 77, "REGULATORY_MANAGEABILITY": 72, "PRE_TOKEN_MONETIZATION_POTENTIAL": 70.0}
|
||||
|
||||
Token Red Team flags: TOKEN_DOES_TOO_MUCH; NATIVE_PAYMENT_NOT_REQUIRED; REVENUE_CLAIM_LANGUAGE; BUYBACK_DEPENDENCY; YIELD_DEPENDENCY
|
||||
|
||||
Validation experiment: On a testnet, simulate a market for 'Rainfall in London' attestations. 10 validators stake 1000 fake credits each. A data producer requests an attestation for a specific day. The validators submit their readings. One validator submits a false reading. The dispute mechanism is triggered. The court of experts reviews the raw sensor logs. The false validator is slashed 50% of their stake. The correct validators earn fees. Measure the time to resolution, the cost of the dispute, and the accuracy of the final consensus. Success criteria: <24h resolution, <5% false positive rate, and validator profit margin >10%.
|
||||
|
||||
## Top 3
|
||||
|
||||
Fewer than 3 qualified; weak token ideas were not promoted.
|
||||
|
||||
## Token Red Team Failures
|
||||
|
||||
{
|
||||
"TOKEN_DOES_TOO_MUCH": 2,
|
||||
"NATIVE_PAYMENT_NOT_REQUIRED": 2,
|
||||
"REVENUE_CLAIM_LANGUAGE": 1,
|
||||
"BUYBACK_DEPENDENCY": 1,
|
||||
"YIELD_DEPENDENCY": 1
|
||||
}
|
||||
|
||||
## Research Health
|
||||
|
||||
{
|
||||
"search_engines": {
|
||||
"RATE_LIMITED": 289,
|
||||
"UNAVAILABLE": 6,
|
||||
"ACCESS_DENIED": 223,
|
||||
"CAPTCHA": 290,
|
||||
"TIMEOUT": 4,
|
||||
"PROTOCOL_ERROR": 29
|
||||
},
|
||||
"sources_accepted": 49,
|
||||
"sources_rejected": 156,
|
||||
"average_coverage": 0.43,
|
||||
"healthy": 0,
|
||||
"rate_limited": 289,
|
||||
"captcha": 290,
|
||||
"denied": 223,
|
||||
"timed_out": 4
|
||||
}
|
||||
|
||||
## Token Utility Distribution
|
||||
|
||||
{
|
||||
"Staking collateral for agents to prove good faith before executing tasks.": 1,
|
||||
"Payment for verification nodes to validate proofs of work.": 1,
|
||||
"Reward mechanism for validators who correctly identify faulty or malicious work.": 1,
|
||||
"Governance voting on protocol parameters such as slashing ratios and verification difficulty.": 1,
|
||||
"Staking: Validators must stake VERI to participate in attestation markets; slashing risk is denominated in VERI.": 1,
|
||||
"Fees: Data producers pay attestation fees in VERI, which are distributed to validators and the protocol treasury.": 1,
|
||||
"Governance: Token holders vote on dispute resolution parameters, validator set composition, and protocol upgrades.": 1,
|
||||
"Collateral: VERI can be used as collateral in the protocol's internal risk management system for high-value attestations.": 1
|
||||
}
|
||||
|
||||
## Capability Gaps
|
||||
|
||||
[
|
||||
{
|
||||
"capability": "Guard model",
|
||||
"count": 2,
|
||||
"status": "AVAILABLE",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "protocol threat modelling",
|
||||
"count": 2,
|
||||
"status": "AVAILABLE",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "Solidity implementation",
|
||||
"count": 2,
|
||||
"status": "AVAILABLE",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "token simulation harness",
|
||||
"count": 2,
|
||||
"status": "AVAILABLE",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "crypto research workflow",
|
||||
"count": 2,
|
||||
"status": "PARTIAL",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "testnet deployment",
|
||||
"count": 2,
|
||||
"status": "PARTIAL",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "wallet auth",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "key management",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "contract deployment pipeline",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "oracle/provider monitoring",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "legal review workflow",
|
||||
"count": 2,
|
||||
"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