Add crypto protocol cohort V0.1 export
This commit is contained in:
Daniel Maddern
parent
11a4c9c6f1
commit
861decb0f8
2 changed files with 1207 additions and 0 deletions
1036
docs/crypto_venture_cohort_v01_20260816.json
Normal file
1036
docs/crypto_venture_cohort_v01_20260816.json
Normal file
File diff suppressed because it is too large
Load diff
171
docs/crypto_venture_cohort_v01_20260816.md
Normal file
171
docs/crypto_venture_cohort_v01_20260816.md
Normal file
|
|
@ -0,0 +1,171 @@
|
|||
# CRYPTO VENTURE COHORT V0.1 REPORT
|
||||
|
||||
Cohort ID: `CPV01-20260816183932-85acae7e`
|
||||
GraphRun: `7`
|
||||
Accepted protocols: `2`
|
||||
Generation attempts: `10`
|
||||
|
||||
## Runtime
|
||||
|
||||
```json
|
||||
{
|
||||
"requested_protocol_count": 10,
|
||||
"generation_attempts": 10,
|
||||
"accepted_protocols": 2,
|
||||
"duplicate_rejections": 0,
|
||||
"token_necessity_rejections": 0,
|
||||
"generation_sources": [
|
||||
"qwen"
|
||||
],
|
||||
"token_unnecessary_rejections": 7,
|
||||
"token_optional_route_to_saas": 3,
|
||||
"crypto_novelty_removed": 0,
|
||||
"hard_exclusion_rejections": 0,
|
||||
"regeneration_attempts": 6,
|
||||
"regenerated_protocols": 6,
|
||||
"unfilled_slots_after_regeneration": 8,
|
||||
"crypto_light_research_seconds": 98.82,
|
||||
"crypto_light_research_sources": 10,
|
||||
"research_insufficient_count": 0,
|
||||
"protocol_security_gate_blocked": 0,
|
||||
"protocol_security_gate_passed": 2,
|
||||
"token_red_team_failures": {},
|
||||
"top5_deep_research_count": 2,
|
||||
"top5_research_coverage_before": {
|
||||
"4070901e-c379-44f9-b802-0c42d97055e2": 0.2,
|
||||
"f21d5c7b-9edc-4f29-a34f-0a80ca10a793": 0.4
|
||||
},
|
||||
"top5_research_coverage_after": {
|
||||
"4070901e-c379-44f9-b802-0c42d97055e2": 0.2,
|
||||
"f21d5c7b-9edc-4f29-a34f-0a80ca10a793": 0.4
|
||||
},
|
||||
"crypto_ranked_count": 2,
|
||||
"crypto_top_3_count": 0,
|
||||
"human_legal_gate_count": 2,
|
||||
"legal_review_required": true
|
||||
}
|
||||
```
|
||||
|
||||
## Ranking
|
||||
|
||||
### Rank 1: API Reliability Slashing Pool
|
||||
|
||||
Decision: `TESTNET_PILOT`. Score: `77.0`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||
|
||||
Product thesis: A testnet marketplace/API where users request measurable digital work and providers compete to fulfill it.
|
||||
|
||||
Protocol thesis: Onchain settlement, escrow, provider bonds, attestations, and slashing coordinate parties that do not share an operator.
|
||||
|
||||
Token thesis: The token is staked by providers, slashed for measurable failures, used for protocol fee settlement, and funds the security budget.
|
||||
|
||||
Token demand loop: users request measurable service; users pay protocol fee; providers stake token to serve; bad providers are slashed; fees reward reliable providers and security budget; more real usage increases fee demand
|
||||
|
||||
Value capture: Usage fees and slashing penalties accrue to reliable providers, insurance/security pool, and protocol treasury.
|
||||
|
||||
Network effect: More users create more jobs; more staked providers improve reliability and lower latency; more attestations improve reputation quality.
|
||||
|
||||
Bootstrap plan: Validate on local/testnet with fake credits and recruited simulated providers; no token sale or mainnet issuance.
|
||||
|
||||
Autonomous operability: `47`. Regulatory manageability: `72`. Security risk score: `93`.
|
||||
|
||||
Scores: {"TOKEN_NECESSITY": 100, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 99, "VALUE_ACCRUAL_QUALITY": 96, "NETWORK_EFFECT_POTENTIAL": 85, "TOKENOMICS_SUSTAINABILITY": 100, "BOOTSTRAPPABILITY": 78, "AUTONOMOUS_OPERABILITY": 47, "SECURITY_MODEL_QUALITY": 93, "REGULATORY_MANAGEABILITY": 72}
|
||||
|
||||
Token Red Team flags: none
|
||||
|
||||
Validation experiment: Run 50 simulated jobs on testnet/local chain, measure provider quality, slashing events, completion cost, and developer API reuse.
|
||||
|
||||
### Rank 2: VeriChain Attestation Exchange
|
||||
|
||||
Decision: `REVISE_TOKEN_MODEL`. Score: `62.4`. Token necessity: `TOKEN_ESSENTIAL`.
|
||||
|
||||
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.
|
||||
|
||||
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`. Regulatory manageability: `72`. Security risk score: `77`.
|
||||
|
||||
Scores: {"TOKEN_NECESSITY": 99, "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}
|
||||
|
||||
Token Red Team flags: none
|
||||
|
||||
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 Utility Distribution
|
||||
|
||||
{
|
||||
"protocol fee settlement": 1,
|
||||
"staking tied to measurable service quality": 1,
|
||||
"slashing / economic guarantees": 1,
|
||||
"decentralized marketplace coordination": 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": "smart contract audit",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "testnet deployment",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"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": "oracle/provider monitoring",
|
||||
"count": 2,
|
||||
"status": "MISSING",
|
||||
"earliest_stage": "BEFORE_VALIDATION"
|
||||
},
|
||||
{
|
||||
"capability": "token simulation harness",
|
||||
"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 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