diff --git a/agents/crypto_venture.py b/agents/crypto_venture.py index c9eb6a3..19f7803 100644 --- a/agents/crypto_venture.py +++ b/agents/crypto_venture.py @@ -680,7 +680,8 @@ class CryptoVentureService: score = min(100, 35 + strong_count * 4 + len(strong_roles) * 8 + len(structural_roles) * 13 + (12 if "slash" in text or "slashing" in text else 0) + (8 if "provider" in text else 0) - (35 if payment_only or weak_only else 0) - (35 if weak else 0) - int(utility_profile.get("SPECULATION_DEPENDENCE", 0) * 0.25)) economic_model = getattr(proposal, "token_economic_model", None) model_payload = {"unit_of_service": economic_model.unit_of_service, "payment_asset": economic_model.payment_asset, "stake_requirement": economic_model.stake_requirement, "collateral_requirement": economic_model.collateral_requirement} if economic_model else {} - judge_prompt = "CRYPTO_TOKEN_UTILITY_JUDGE V0.3.2B. Independent from ideation, onchain review, and token design. Challenge the token; do not merely summarize it. A native token need not be mathematically impossible to substitute, but benefits must outweigh costs. Evaluate security quality, attack economics, slashing effectiveness, provider skin-in-the-game, capital efficiency, protocol-specific risk pricing, permissionless supply formation, participant coordination, resource allocation, reputation portability, value capture, network effects, bootstrapping economics, governance, and composability versus USDC/ETH/external collateral/non-transferable attestations. Return JSON with token_classification TOKEN_ESSENTIAL/TOKEN_STRONGLY_JUSTIFIED/TOKEN_OPTIONAL/TOKEN_UNNECESSARY; score 0-100; utility_scores object; strong_structural_roles list; weak_roles list; counterfactual_analysis; external_collateral_counterfactual object/string; material_improvements_over_USDC_ETH non-empty list; native_asset_costs_and_risks non-empty list; argument_for_native_token non-empty string; argument_against_native_token non-empty string; final_rationale non-empty string; native_token_removed_breaks non-empty list; native_token_removed_degradation NONE/MINOR/MODERATE/MATERIAL/CRITICAL; native_token_removed_explanation non-empty string. If TOKEN_OPTIONAL, final_rationale must answer: Why is ETH/USDC/external collateral preferable despite the claimed material degradation? If TOKEN_ESSENTIAL or TOKEN_STRONGLY_JUSTIFIED, final_rationale must answer: What protocol-specific property cannot be reproduced economically enough with ETH/USDC/external collateral? Do not automatically promote for material degradation. Product/protocol/token/economic model: " + json.dumps({"pitch": proposal.pitch, "crypto": crypto, "roles": roles.roles, "utility_profile": utility_profile, "economic_model": model_payload}, default=str) + judge_context = {"title": proposal.title, "product_thesis": crypto.get("product_thesis") or proposal.description, "protocol_thesis": crypto.get("protocol_thesis") or getattr(proposal, "protocol_thesis", None).protocol_thesis if hasattr(proposal, "protocol_thesis") else "", "token_thesis": crypto.get("token_thesis") or proposal.pitch.get("Token thesis", ""), "token_utility": utilities, "token_demand_loop": proposal.pitch.get("Token demand loop", []), "value_capture": crypto.get("value_capture", ""), "token_roles": roles.roles, "utility_profile": utility_profile, "economic_model": model_payload} + judge_prompt = "CRYPTO_TOKEN_UTILITY_JUDGE V0.3.2B. Return strict JSON only. Required fields: token_classification TOKEN_ESSENTIAL/TOKEN_STRONGLY_JUSTIFIED/TOKEN_OPTIONAL/TOKEN_UNNECESSARY; score 0-100; utility_scores object; strong_structural_roles list; weak_roles list; counterfactual_analysis object including external_collateral_identical_security and stable_collateral_identical_security booleans; external_collateral_counterfactual non-empty object/string; material_improvements_over_USDC_ETH non-empty list; native_asset_costs_and_risks non-empty list; argument_for_native_token non-empty string; argument_against_native_token non-empty string; final_rationale non-empty string; native_token_removed_breaks non-empty list; native_token_removed_degradation NONE/MINOR/MODERATE/MATERIAL/CRITICAL; native_token_removed_explanation non-empty string. If TOKEN_OPTIONAL, final_rationale must answer why ETH/USDC/external collateral is preferable despite claimed material degradation. If TOKEN_ESSENTIAL or TOKEN_STRONGLY_JUSTIFIED, final_rationale must answer what protocol-specific property cannot be reproduced economically enough with ETH/USDC/external collateral. Do not automatically promote. Judge context: " + json.dumps(judge_context, default=str) sol_review = self._complete_token_utility_judge(judge_prompt, roles.roles) sol_structural_roles = [str(role) for role in self._as_list((sol_review or {}).get("strong_structural_roles")) if str(role) in STRUCTURAL_TOKEN_ROLES] sol_scores = (sol_review or {}).get("utility_scores", {}) if isinstance((sol_review or {}).get("utility_scores", {}), dict) else {} @@ -723,7 +724,7 @@ class CryptoVentureService: score = min(score, 62) proposal.metadata = {**proposal.metadata, "crypto": {**crypto, "token_utility_judge_model": self.final_ic_model_hint, "token_utility_judge_used": bool(sol_review), "token_utility_profile": utility_profile, "strong_structural_roles": structural_roles, "strong_token_roles": strong_roles}} proposal.save(update_fields=["metadata", "updated_at"]) - return TokenUtilityAssessment.objects.update_or_create(proposal=proposal, defaults={"classification": classification, "token_necessity_score": score, "utility_categories": utilities, "fiat_or_database_substitution": str((sol_review or {}).get("counterfactual_analysis", "USDC/ETH/external collateral may preserve basic operation but must be compared against protocol-specific security and coordination improvements.")), "rationale": str((sol_review or {}).get("final_rationale") or (sol_review or {}).get("rationale") or "Token score derives from structural utility, not native payment currency alone."), "metadata": {"weak_utility_terms": INSUFFICIENT_TOKEN_UTILITIES, "sol_counterfactual_review": sol_review or {}, "sol_token_utility_judge": sol_review or {}, "independent_token_utility_judge": "CRYPTO_TOKEN_UTILITY_JUDGE", "argument_for_native_token": (sol_review or {}).get("argument_for_native_token", ""), "argument_against_native_token": (sol_review or {}).get("argument_against_native_token", ""), "utility_scores": utility_profile, "strong_structural_roles": structural_roles, "strong_token_roles": strong_roles, "weak_roles": (sol_review or {}).get("weak_roles", []), "counterfactual_analysis": (sol_review or {}).get("counterfactual_analysis", ""), "external_collateral_counterfactual": (sol_review or {}).get("external_collateral_counterfactual", {}), "material_improvements_over_USDC_ETH": self._as_list((sol_review or {}).get("material_improvements_over_USDC_ETH")), "native_asset_costs_and_risks": self._as_list((sol_review or {}).get("native_asset_costs_and_risks")), "required_roles": roles.required_roles, "payment_only_penalty": payment_only, "native_token_removed_breaks": self._as_list((sol_review or {}).get("native_token_removed_breaks")), "native_token_removed_degradation": degradation, "native_token_removed_explanation": (sol_review or {}).get("native_token_removed_explanation", "")}})[0] + return TokenUtilityAssessment.objects.update_or_create(proposal=proposal, defaults={"classification": classification, "token_necessity_score": score, "utility_categories": utilities, "fiat_or_database_substitution": str((sol_review or {}).get("counterfactual_analysis", "USDC/ETH/external collateral may preserve basic operation but must be compared against protocol-specific security and coordination improvements.")), "rationale": str((sol_review or {}).get("final_rationale") or (sol_review or {}).get("rationale") or "Token score derives from structural utility, not native payment currency alone."), "metadata": {"weak_utility_terms": INSUFFICIENT_TOKEN_UTILITIES, "sol_counterfactual_review": sol_review or {}, "sol_token_utility_judge": sol_review or {}, "independent_token_utility_judge": "CRYPTO_TOKEN_UTILITY_JUDGE", "argument_for_native_token": (sol_review or {}).get("argument_for_native_token", ""), "argument_against_native_token": (sol_review or {}).get("argument_against_native_token", ""), "utility_scores": utility_profile, "strong_structural_roles": structural_roles, "strong_token_roles": strong_roles, "weak_roles": (sol_review or {}).get("weak_roles", []), "counterfactual_analysis": (sol_review or {}).get("counterfactual_analysis", ""), "external_collateral_counterfactual": (sol_review or {}).get("external_collateral_counterfactual", {}), "material_improvements_over_USDC_ETH": self._as_list((sol_review or {}).get("material_improvements_over_USDC_ETH")), "native_asset_costs_and_risks": self._as_list((sol_review or {}).get("native_asset_costs_and_risks")), "required_roles": roles.required_roles, "payment_only_penalty": payment_only, "native_token_removed_breaks": self._as_list((sol_review or {}).get("native_token_removed_breaks")), "native_token_removed_degradation": degradation, "native_token_removed_explanation": (sol_review or {}).get("native_token_removed_explanation", ""), "final_rationale": (sol_review or {}).get("final_rationale", "")}})[0] def token_role_decomposition(self, proposal: CompanyProposal) -> TokenRoleDecomposition: text = self._design_text(proposal) @@ -973,7 +974,7 @@ class CryptoVentureService: return labs def crypto_score_row(self, proposal: CompanyProposal) -> dict[str, Any]: - token = self.assess_token_necessity(proposal) + token = getattr(proposal, "token_utility_assessment", None) or self.assess_token_necessity(proposal) onchain = self.onchain_assessment(proposal) value = self.value_capture_assessment(proposal) policy = self.regulatory_policy(proposal) @@ -1042,7 +1043,8 @@ class CryptoVentureService: return CryptoICDecisionType.PROTOCOL_VALIDATE def _sol_final_ic_adjustment(self, row: dict[str, Any]) -> dict[str, Any]: - review = self._sol_json("Final Crypto IC review V0.3.1. Consider problem thesis, protocol thesis, token utility profile, independent token judge, Token Red Team, Guard assessment, token economic model, simulation, primary-source evidence, autonomy analysis, pre-token business, and uncertainty. Return JSON with optional score_adjustment -20..20, decision from TESTNET_PILOT, PROTOCOL_VALIDATE, REVISE_TOKEN_MODEL, ASSISTED_CRYPTO_HIGH_POTENTIAL, WATCHLIST, ROUTE_TO_VENTURE_STUDIO, REJECT_TOKEN_NOT_NEEDED, REJECT_TOKEN_UTILITY_WEAK, REJECT_ONCHAIN_NOT_NEEDED, REJECT_SECURITY_MODEL, REJECT_ECONOMIC_MODEL, REJECT_AUTONOMY, REJECT_NO_DEMAND, and rationale. Do not promote weak token ideas or fill finalist slots. Row: " + json.dumps(row, default=str)) + compact_row = {key: row.get(key) for key in ["company", "product_thesis", "protocol_thesis", "token_thesis", "why_token", "token_necessity_classification", "token_utility_scores", "strong_token_roles", "strong_structural_roles", "argument_for_native_token", "argument_against_native_token", "external_collateral_counterfactual", "native_token_removed_degradation", "native_token_removed_explanation", "token_red_team_flags", "component_scores", "crypto_ic_score", "crypto_ic_decision"]} + review = self._sol_json("Final Crypto IC review V0.3.2B. Return JSON only with score_adjustment -20..20, decision from TESTNET_PILOT, PROTOCOL_VALIDATE, REVISE_TOKEN_MODEL, ASSISTED_CRYPTO_HIGH_POTENTIAL, WATCHLIST, ROUTE_TO_VENTURE_STUDIO, REJECT_TOKEN_NOT_NEEDED, REJECT_TOKEN_UTILITY_WEAK, REJECT_ONCHAIN_NOT_NEEDED, REJECT_SECURITY_MODEL, REJECT_ECONOMIC_MODEL, REJECT_AUTONOMY, REJECT_NO_DEMAND, and rationale. Consider the repaired token utility judge evidence, red-team flags, and component scores. Do not promote weak token ideas or fill finalist slots. Row: " + json.dumps(compact_row, default=str)) if not review: return row adjustment = max(-20, min(20, float(review.get("score_adjustment", 0)))) @@ -1107,6 +1109,7 @@ class CryptoVentureService: last_missing: list[str] = [] for attempt in range(attempts): review = self._sol_json(prompt + retry_hint) + review = self._normalize_token_judge_response(review) missing = self._token_judge_missing_fields(review, roles) if not missing: return review @@ -1114,6 +1117,20 @@ class CryptoVentureService: retry_hint = "\nPrevious token utility judge response was rejected because these required fields or rationale checks were empty/incomplete: " + json.dumps(missing) + ". Return a complete JSON object only." raise ValueError("Incomplete Sol token utility judge response: " + ", ".join(last_missing)) + def _normalize_token_judge_response(self, review: dict[str, Any]) -> dict[str, Any]: + if not isinstance(review, dict): + return {} + normalized = dict(review) + counterfactual = normalized.get("counterfactual_analysis") + if isinstance(counterfactual, dict) and self._empty_judge_value(normalized.get("external_collateral_counterfactual")): + nested = counterfactual.get("external_collateral_counterfactual") + if not self._empty_judge_value(nested): + normalized["external_collateral_counterfactual"] = nested + scores = normalized.get("utility_scores") + if isinstance(scores, dict): + normalized["utility_scores"] = {str(key).upper(): value for key, value in scores.items()} + return normalized + def _token_judge_missing_fields(self, review: dict[str, Any], roles: dict[str, Any]) -> list[str]: if not review: return ["judge_response"] diff --git a/control_plane/ventures/management/commands/export_crypto_venture_cohort.py b/control_plane/ventures/management/commands/export_crypto_venture_cohort.py index 2ebb1a1..98ec5d8 100644 --- a/control_plane/ventures/management/commands/export_crypto_venture_cohort.py +++ b/control_plane/ventures/management/commands/export_crypto_venture_cohort.py @@ -134,6 +134,17 @@ class Command(BaseCommand): lines.extend(f"- {row['company']}: `{row['crypto_ic_decision']}`" for row in top_3) else: lines.append("Fewer than 3 qualified; weak token ideas were not promoted.") + before_after = payload.get("v032b_before_after_classifications", []) + if before_after: + lines.extend(["", "## V0.3.2B Before/After", ""]) + for row in before_after: + lines.extend( + [ + f"- {row.get('company')}: `{row.get('before')}` -> `{row.get('after')}`. Score: `{row.get('score')}`. Final IC: `{row.get('final_ic_decision')}` at `{row.get('final_ic_score')}`.", + f" Required field gaps: {self.inline(row.get('required_field_gaps', []))}", + f" Final rationale: {row.get('final_rationale', '')}", + ] + ) routed = payload.get("routed_to_saas", []) lines.extend(["", "## Routed To SaaS", ""]) if routed: diff --git a/docs/crypto_venture_cohort_v031_20260816.json b/docs/crypto_venture_cohort_v031_20260816.json index c733c0c..dd42989 100644 --- a/docs/crypto_venture_cohort_v031_20260816.json +++ b/docs/crypto_venture_cohort_v031_20260816.json @@ -1,5 +1,5 @@ { - "title": "CRYPTO VENTURE COHORT V0.3.1 CORRECTED", + "title": "CRYPTO VENTURE COHORT V0.3.2B TOKEN JUDGE EVIDENCE REPAIR", "cohort_id": "CPV031-20260816215626-66d636b2", "graph_run": "10", "runtime": { @@ -31,10 +31,10 @@ "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": 6, + "token_unnecessary_rejections": 1, + "token_optional_route_to_saas": 4, "token_essential": 0, - "token_strongly_justified": 0, + "token_strongly_justified": 1, "serious_crypto_survivors": 0, "crypto_survivors": 0, "token_design_attempts": 11, @@ -55,7 +55,7 @@ "protocol_security_gate_blocked": 0, "protocol_security_gate_passed": 0, "token_red_team_failures": { - "TOKEN_NOT_REQUIRED": 6, + "TOKEN_NOT_REQUIRED": 5, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 }, @@ -82,6 +82,71 @@ "TOKEN_NOT_REQUIRED": 6, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 + }, + "v032b_existing_six_token_judge": 6, + "v032b_existing_six_red_team": 6, + "v032b_existing_six_final_ic": 6, + "v032b_before_after_classifications": [ + { + "company": "Agent Passport Clearinghouse", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_UNNECESSARY", + "score": 18.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 62.3 + }, + { + "company": "PatchBond Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 48.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 66.4 + }, + { + "company": "ProofGrid Compute Attestation Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 42.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 63.6 + }, + { + "company": "ProofBond", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 54.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 64.3 + }, + { + "company": "Compute Clearance Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_STRONGLY_JUSTIFIED", + "score": 78.0, + "required_field_gaps": [], + "final_ic_decision": "PROTOCOL_VALIDATE", + "final_ic_score": 79.7 + }, + { + "company": "ProofGrid Compute Escrow", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 58.0, + "required_field_gaps": [], + "final_ic_decision": "REVISE_TOKEN_MODEL", + "final_ic_score": 67.9 + } + ], + "v032b_required_field_gaps": 0, + "v032b_token_red_team_failures": { + "TOKEN_NOT_REQUIRED": 5, + "YIELD_DEPENDENCY": 1, + "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 } }, "raw_protocols_generated": 20, @@ -90,9 +155,9 @@ "onchain_rejected": 9, "token_design_attempts": 11, "token_design_skipped": 9, - "token_unnecessary": 5, - "token_optional_routed_saas": 6, - "token_strongly_justified": 0, + "token_unnecessary": 1, + "token_optional_routed_saas": 4, + "token_strongly_justified": 1, "token_essential": 0, "crypto_survivors": 0, "autonomous_crypto_survivors": 0, @@ -111,6 +176,304 @@ }, "ranking": [], "top_3": [], + "v032b_before_after_classifications": [ + { + "company": "Agent Passport Clearinghouse", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_UNNECESSARY", + "score": 18.0, + "required_field_gaps": [], + "argument_for_native_token": "A native token could concentrate economic upside around the clearinghouse, fund early security budgets, give providers a shared coordination asset, and create a unified stake/reward medium for trust providers and resolvers.", + "argument_against_native_token": "The core functions are identity, attestation aggregation, delegated authority records, dispute history, reputation, and slashable accountability. None require a proprietary asset; USDC, ETH, or other liquid collateral can provide the same bonding and slashing mechanics with lower volatility and higher counterparty confidence.", + "external_collateral_counterfactual": { + "description": "Trust providers, agents, and dispute resolvers post USDC, ETH, tokenized T-bills, insurance-backed guarantees, or venue-approved collateral into escrow contracts. Slashing, admission thresholds, credit limits, and dispute penalties operate the same way without requiring a native asset.", + "security_result": "Equivalent or better, because collateral value is more liquid, easier to price, less reflexive, and more acceptable to counterparties." + }, + "native_token_removed_breaks": [ + "No essential protocol function breaks.", + "Security bonds can be denominated in USDC, ETH, or other approved collateral.", + "Slashable resolver and trust-provider accountability remains intact.", + "Agent bonds and acceptance limits remain intact.", + "Usage fees and treasury revenue can accrue in stablecoins or fiat." + ], + "native_token_removed_degradation": "MINOR", + "native_token_removed_explanation": "Removing the native token may reduce speculative bootstrapping and captive value capture, but it does not materially impair trust attestations, resolver slashing, agent bonding, payment reputation, or credential records.", + "material_improvements_over_USDC_ETH": [ + "No material protocol-specific improvement over USDC or ETH is identified. A native token could create a captive collateral asset and speculative upside for early participants, but those are not necessary for agent identity, attestations, bonding, or resolver accountability." + ], + "native_asset_costs_and_risks": [ + "Collateral volatility weakens bond reliability and requires larger haircuts.", + "Thin liquidity can make slashing proceeds less useful to harmed counterparties.", + "Token price reflexivity can reduce security exactly when protocol trust is under stress.", + "Adds regulatory and governance complexity without a clear functional necessity.", + "Creates adoption friction for agents, enterprises, marketplaces, and compliance providers that prefer stable or widely accepted collateral." + ], + "final_rationale": "The protocol has real collateral and slashing needs, but those needs are not native-token-specific. ETH, USDC, tokenized cash instruments, or insurance-backed collateral can economically reproduce the security model while improving price stability, liquidity, and institutional acceptance. The native token mainly adds captive value capture and bootstrapping optionality, not an essential protocol-specific property.", + "red_team_flags": [ + "TOKEN_NOT_REQUIRED" + ], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 62.3, + "sol_final_ic_review": { + "score_adjustment": -8, + "decision": "REJECT_TOKEN_NOT_NEEDED", + "rationale": "Strong product and protocol thesis with real demand for agent identity, authority, attestations, reputation, dispute history, and delegated trust records. However, the repaired token utility evidence confirms the native token is not structurally necessary: the strongest roles are bonding, slashing, and security collateral, all of which are better served by ETH, USDC, tokenized cash instruments, insurance-backed guarantees, or venue-approved collateral. Native-token removal causes only minor degradation, mainly reducing speculative bootstrapping and captive value capture rather than impairing core protocol function. Component scores support this split: real usage demand, onchain necessity, value accrual quality, network effects, and security model are strong, but TOKEN_NECESSITY is very weak at 18 and the red-team flag is TOKEN_NOT_REQUIRED. This may be a high-quality venture or protocol business, but not a justified native token opportunity." + } + }, + { + "company": "PatchBond Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 48.0, + "required_field_gaps": [], + "argument_for_native_token": "The strongest case for a native token is that PatchBond needs slashable, usage-linked collateral for vendors and assessors, and a native asset can coordinate provider admission, early network bootstrapping, treasury funding, and shared downside exposure in a single mechanism.", + "argument_against_native_token": "The strongest case against a native token is that the protocol's core product is credible remediation assurance for enterprise buyers, and that credibility is better served by liquid, stable, externally enforceable collateral such as USDC, ETH, fiat escrow, bank guarantees, or insurance-backed instruments.", + "external_collateral_counterfactual": { + "design": "Use USDC, ETH, fiat escrow, bank guarantees, or regulated insurance collateral for vendor bonds while charging protocol fees in stablecoin or fiat.", + "effect": "This preserves most buyer-facing trust, payout certainty, and procurement evidence while removing native-token volatility and liquidity risk." + }, + "native_token_removed_breaks": [ + "Native-token staking as the default provider admission mechanism", + "Direct native-token slashing into a protocol-controlled security budget", + "Token-denominated rewards for early assessors or infrastructure providers", + "Protocol treasury value capture through native-token demand" + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens native staking, bootstrapping incentives, and token-based treasury capture, but it does not break the core PatchBond workflow. Vendors can still post externally valuable collateral, assessors can still verify incidents, buyers can still compare bond histories, and claims can still be paid through stablecoin, ETH, fiat escrow, or insurance-backed structures.", + "material_improvements_over_USDC_ETH": [ + "A native token can bind assessors, vendors, and service providers to the same network-specific risk budget.", + "Native staking can create protocol-level admission costs for assessors or bond underwriters.", + "Slashing a native token can redirect losses to a treasury or security pool without relying only on external payment rails.", + "Token rewards may help bootstrap early assessor and provider participation before fee volume is sufficient.", + "A native asset may create a shared economic identity for recurring vendors and verifiers across many bond categories." + ], + "native_asset_costs_and_risks": [ + "Native-token volatility weakens bond credibility because buyers want predictable remediation payouts.", + "Thin liquidity can make large slashing events hard to convert into usable compensation.", + "Vendors and enterprise buyers may resist holding or accounting for a speculative asset.", + "Collateral value can fall at the same time network confidence deteriorates, reducing security exactly when claims rise.", + "Using a native asset introduces regulatory, custody, tax, and procurement friction compared with USDC, ETH, fiat escrow, or insurance.", + "Native-token incentives may distort assessor behavior if token price support becomes more important than accurate vulnerability adjudication." + ], + "final_rationale": "PatchBond has real collateral and slashing needs, but the protocol-specific property is not strong enough to make a native token necessary. The core security function is an enforceable vendor bond with independent assessment and predictable payout conditions, which USDC, ETH, fiat escrow, bank guarantees, or insurance collateral can reproduce more credibly for enterprise procurement. Although removing the token moderately degrades bootstrapping, native provider admission, and treasury value capture, external collateral is preferable because buyers value payout certainty, liquidity, accounting simplicity, and legal enforceability more than native-token reflexive security.", + "red_team_flags": [ + "TOKEN_NOT_REQUIRED" + ], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 66.4, + "sol_final_ic_review": { + "score_adjustment": -6, + "decision": "REJECT_TOKEN_NOT_NEEDED", + "rationale": "PatchBond has a credible enterprise security-assurance market, strong real demand, good onchain standardization potential, and high-quality collateral/slashing workflows. However, the repaired token utility evidence explicitly classifies the token as TOKEN_OPTIONAL, flags TOKEN_NOT_REQUIRED, and shows the core buyer-facing value is better served by USDC, ETH, fiat escrow, bank guarantees, legal agreements, or insurance-backed collateral. Native-token removal causes only moderate degradation and does not break vendor bonds, assessor verification, buyer procurement evidence, or claims payouts. Strong collateral and slashing needs support a protocol, but not a volatile native asset. Do not promote to pilot or protocol validation as a tokenized crypto investment until the model removes or sharply limits the native token." + } + }, + { + "company": "ProofGrid Compute Attestation Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 42.0, + "required_field_gaps": [], + "argument_for_native_token": "The best case for a native token is that ProofGrid is not merely a compute marketplace but a neutral cross-market security and reputation layer. A native asset could unify provider bonds, verifier bonds, machine identity, reputation portability, slashing, and security-budget funding under one endogenous incentive system.", + "argument_against_native_token": "The core trust problem is solved by attestations, reproducibility checks, dispute evidence, reputation records, and slashable collateral. None of these require the collateral to be a new volatile asset. USDC, ETH, or other liquid collateral can reproduce the economic security more cleanly and with less adoption friction.", + "external_collateral_counterfactual": { + "bond_asset": "USDC, ETH, tokenized T-bills, or approved liquid collateral", + "mechanism": "Providers and verifiers post external collateral into slashing contracts. Hardware attestations, job proofs, benchmark records, dispute evidence, and reputation remain protocol-native data objects, while economic penalties are denominated in liquid collateral.", + "security_result": "Fraud, SLA failure, lazy verification, and collusion remain slashable. Bond sizing can be risk-tiered by job value, hardware class, verifier history, and workload reproducibility without requiring a volatile native asset.", + "tradeoff": "The protocol loses some endogenous token demand and upside capture, but gains more predictable collateral value and lower buyer/provider friction." + }, + "native_token_removed_breaks": [ + "No core attestation function breaks; hardware proofs and job evidence can still be recorded.", + "No core slashing function breaks; providers and verifiers can post USDC, ETH, or approved collateral.", + "No core payment function breaks; settlement is already stablecoin-or-fiat oriented.", + "No core reputation function breaks; reputation can attach to identities and bonded records independent of collateral asset." + ], + "native_token_removed_degradation": "MINOR", + "native_token_removed_explanation": "Removing the native token modestly reduces endogenous token demand, speculative bootstrap incentives, and protocol-owned security-budget capture. It does not materially impair provider admission, verifier bonding, machine identity, dispute resolution, or risk-tiered collateral because those mechanisms can be implemented with external collateral and protocol-native records.", + "material_improvements_over_USDC_ETH": [ + "A native token could align early providers, verifiers, and governance participants around the growth of the attestation network.", + "A native token could make machine identity and reputation economically portable under one common collateral unit.", + "A native token could route some protocol fees into a security budget or staking yield without relying on external collateral integrations.", + "A native token could bootstrap supply-side participation before compute fees are large enough to fund verifier rewards." + ], + "native_asset_costs_and_risks": [ + "Volatile collateral weakens bond reliability exactly when slashing protection must be predictable.", + "Providers may face forced token inventory risk unrelated to their compute business.", + "Buyers likely prefer stablecoin or fiat payments, so mandatory native-token payment would add friction.", + "Security can become reflexive if token price falls during a trust or fraud crisis.", + "The token can shift focus from verified compute quality to speculative staking demand.", + "External collateral is easier to value for dispute resolution, insurance, and enterprise procurement." + ], + "final_rationale": "TOKEN_OPTIONAL because the native token may help bootstrap and coordinate a portable attestation network, but the core security model does not require it. ETH, USDC, or approved external collateral is preferable because slashing needs predictable, liquid, widely accepted value, while the protocol-specific properties such as machine identity, verifier reputation, routing eligibility, and dispute records can be represented as protocol state backed by external bonds. Any degradation from removing the token is mainly loss of endogenous value capture and bootstrap alignment, not loss of the attestation or slashing function itself.", + "red_team_flags": [ + "TOKEN_NOT_REQUIRED" + ], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 63.6, + "sol_final_ic_review": { + "score_adjustment": -6, + "decision": "REJECT_TOKEN_UTILITY_WEAK", + "rationale": "Repaired token utility evidence confirms the core protocol is credible but the native token remains optional. Attestation records, verifier accountability, dispute evidence, provider admission, machine reputation, and slashing can be implemented with protocol state plus external collateral such as USDC, ETH, or tokenized T-bills. Native-token removal causes only MINOR degradation, mostly reducing endogenous value capture and bootstrap alignment rather than breaking security or utility. Strong component scores for demand, onchain necessity, value accrual design, network effects, tokenomics, and security do not overcome the red-team TOKEN_NOT_REQUIRED flag or the low token-necessity score. Do not advance as a crypto/token finalist unless the model is revised around external collateral or a materially stronger unavoidable native-token role." + } + }, + { + "company": "ProofBond", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 54.0, + "required_field_gaps": [], + "argument_for_native_token": "A native token gives ProofBond a unified economic identity and staking layer: machine operators, verifiers, and reviewers all hold slashable exposure to the same network whose reputation they secure, while fee-driven value capture can support a dedicated security budget and long-term participant alignment.", + "argument_against_native_token": "The essential security primitive is not a native asset; it is credible, liquid, slashable collateral backing measurable machine-performance claims. USDC or ETH can provide equal or better compensation certainty with lower volatility, simpler onboarding, and less speculative distortion.", + "external_collateral_counterfactual": { + "accepted_collateral": [ + "USDC", + "ETH", + "liquid staking tokens", + "tokenized treasury assets where legally and operationally appropriate" + ], + "mechanism": "Capability claims are bonded with external collateral, slashed for failed claims or malicious verification, and linked to machine identities through non-transferable credentials and historical performance records.", + "why_viable": "ProofBond mainly needs credible collateral, objective measurement, dispute resolution, and portable reputation. These are enforceable with external assets and do not require a proprietary monetary asset." + }, + "native_token_removed_breaks": [ + "direct native-token demand loop from operator bonding", + "single proprietary asset for verifier staking and assignment rights", + "native-token-based security budget design", + "direct treasury value capture from mandatory bond demand" + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens protocol-native alignment and value capture, but it does not break the core product. Operators can still bond claims, verifiers can still stake, disputes can still slash collateral, and buyers can still route work based on bonded track records using USDC or ETH collateral.", + "material_improvements_over_USDC_ETH": [ + "Native token can internalize protocol-specific upside for operators and verifiers.", + "Native token can serve as a unified staking and assignment-rights asset across operator bonds, verifier credibility, and dispute review.", + "Native token can improve protocol fee capture if fees are used to support staking rewards, buybacks, burns, or insurance reserves.", + "Native token can create a bootstrapping mechanism for early supply-side participation before fee revenue is sufficient." + ], + "native_asset_costs_and_risks": [ + "Native collateral volatility weakens buyer protection because slash value may fall when compensation is needed.", + "Operators face additional inventory and hedging costs versus posting USDC or ETH.", + "Speculative demand can distort verifier assignment and provider admission, favoring token holders over the most reliable machines.", + "A native token adds regulatory, liquidity, market-maker, exchange, and treasury-management complexity.", + "If token price declines, the protocol may need larger nominal bond requirements, increasing UX friction and reducing trust.", + "External buyers may prefer dollar-denominated guarantees over exposure to an unfamiliar protocol asset." + ], + "final_rationale": "ProofBond has real collateral and slashing needs, but the protocol-specific property claimed for the native token can be reproduced economically enough with ETH, USDC, or other external collateral. Portable machine reputation, verifier staking, dispute slashing, provider admission, and routing priority can all be implemented using external collateral plus non-transferable machine credentials and contract-enforced penalties. Although removing the native token causes moderate degradation in endogenous alignment, fee capture, and bootstrapping flexibility, ETH and especially USDC are preferable for the core guarantee because they are more liquid, more legible to buyers, less volatile, and provide clearer compensation value when claims fail.", + "red_team_flags": [ + "TOKEN_NOT_REQUIRED" + ], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 64.3, + "sol_final_ic_review": { + "score_adjustment": -8, + "decision": "REJECT_TOKEN_UTILITY_WEAK", + "rationale": "ProofBond has a credible crypto-relevant market and strong demand/onchain components, but the repaired token utility evidence confirms the native token is optional rather than necessary. The core functions, including bonding machine claims, verifier staking, dispute slashing, provider admission, routing priority, and portable reputation, can be implemented with USDC/ETH collateral plus non-transferable machine credentials. Red-team flag TOKEN_NOT_REQUIRED is decisive: native token removal causes only moderate degradation and does not break the protocol. Do not advance as a token finalist despite otherwise strong product and protocol scores." + } + }, + { + "company": "Compute Clearance Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_STRONGLY_JUSTIFIED", + "score": 78.0, + "required_field_gaps": [], + "argument_for_native_token": "A native token is strongly justified if the network wants machine identities, providers, verifiers, and solvers to post protocol-specific slashable stake that persists across jobs and directly links reputation, admission, routing power, and security budget to the health of the compute clearance network.", + "argument_against_native_token": "Most payment, settlement, and compensation functions can be performed more cleanly with USDC, ETH, or other external collateral, and stable collateral is often better for predictable buyer protection than a volatile native token.", + "external_collateral_counterfactual": { + "description": "The protocol could accept USDC, ETH, or liquid staking tokens as provider, verifier, and solver collateral. This would likely improve collateral stability and user familiarity, but it would make the accountability layer more generic and less coupled to machine identity, reputation, network-specific risk, and protocol security budget formation.", + "advantages": [ + "Lower volatility for collateral denominated in USDC", + "Better liquidity and easier risk management", + "Less reflexive collapse risk during protocol stress", + "Simpler buyer/provider onboarding" + ], + "limitations": [ + "Collateral demand would not create protocol-native economic lockup proportional to compute-network risk", + "Machine identities would be secured by rented external capital rather than by a protocol-specific stake whose value is linked to long-term network trust", + "Slashing external collateral compensates victims but does not directly increase native security alignment or make reputation capital harder to port away", + "External collateral can reproduce financial penalty but not as cleanly reproduce token-denominated admission, reputation, and security-budget coupling" + ] + }, + "native_token_removed_breaks": [ + "Native risk-proportional token lockup tied to active service commitments", + "Protocol-native machine economic identity secured by continued staking", + "Direct coupling between reputation, admission, earning capacity, and native collateral", + "Slashing-driven recapitalization of native security or insurance pools", + "Token-based solver, verifier, and provider accountability across repeated interactions" + ], + "native_token_removed_degradation": "MATERIAL", + "native_token_removed_explanation": "Removing the native token would not break the compute marketplace or SLA settlement entirely because USDC, ETH, or other collateral could still support payments, bonds, and slashing. However, it would materially degrade the protocol-specific accountability layer by turning provider, verifier, solver, and machine commitments into generic collateral deposits rather than persistent native economic identities tied to reputation, admission, routing power, and the network security budget.", + "material_improvements_over_USDC_ETH": [ + "Creates a protocol-specific slashable identity layer for machines, providers, verifiers, and solvers rather than relying only on generic rented collateral", + "Links earning capacity and reputation to continued bonded participation in the same network", + "Makes active service commitments create structural native-token lockup proportional to operational risk", + "Allows slashing to reinforce protocol-native security pools, verifier rewards, or buyer-compensation pools", + "Improves coordination around scarce capacity, routing rights, and admission through a common risk-bearing asset" + ], + "native_asset_costs_and_risks": [ + "Native token volatility can weaken collateral reliability during market stress", + "Providers may need to hedge token exposure, increasing operating complexity", + "Security can become reflexive if token price falls when confidence in the network declines", + "USDC or ETH may be superior for buyer payments and deterministic compensation amounts", + "Speculative demand can distort the cost of participation for real compute providers", + "Regulatory and market-structure risk is higher than using external payment and collateral assets" + ], + "final_rationale": "The token is strongly justified but not essential. The protocol-specific property that cannot be reproduced economically enough with ETH, USDC, or generic external collateral is the combination of persistent bonded machine identity, reputation-linked earning capacity, risk-proportional native lockup, and slashing that recapitalizes a protocol-native security budget. External collateral can reproduce financial penalties, but it does not create the same endogenous accountability layer where compute capacity, routing, verification, and machine reputation are all secured by stake whose value and opportunity cost are tied to the network itself.", + "red_team_flags": [], + "final_ic_decision": "PROTOCOL_VALIDATE", + "final_ic_score": 79.7, + "sol_final_ic_review": { + "score_adjustment": 2, + "decision": "PROTOCOL_VALIDATE", + "rationale": "Repaired token utility evidence supports a materially stronger native-token case than a generic compute marketplace: slashable protocol-native collateral tied to machine identity, reputation, routing power, verifier accuracy, provider admission, and security budget formation is a coherent utility thesis. Component scores are strong on value accrual, tokenomics sustainability, real demand, network effects, and security model, with no red-team flags. However, the token remains not strictly essential because external collateral can cover payments, bonds, and some slashing, and bootstrappability plus autonomous operability are only moderate. This warrants validation of protocol mechanics, SLA observability, slashing objectivity, and supply/demand liquidity before any higher-conviction pilot." + } + }, + { + "company": "ProofGrid Compute Escrow", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 58.0, + "required_field_gaps": [], + "argument_for_native_token": "ProofGrid has a credible native-token argument because its core problem is not payment but trust formation across independent GPU hosts, verifiers, marketplaces, and machine identities. A slashable native bond can bind suppliers and verifiers to portable reputation, make machine identity abandonment costly, and create an endogenous security budget for verification and disputes.", + "argument_against_native_token": "The same escrow, slashing, admission, and reputation mechanics can mostly be implemented with USDC or ETH collateral plus protocol-specific non-transferable reputation records. Compute buyers care about predictable compensation and verification quality, not exposure to a volatile protocol asset. Native-token volatility and speculation may reduce rather than improve security per dollar bonded.", + "external_collateral_counterfactual": { + "description": "Suppliers and verifiers could bond ETH, USDC, or a diversified external collateral basket while reputation, machine identity, routing priority, job history, and slashing logic remain protocol-specific non-transferable records. Escrows can remain in stablecoins. Slashed collateral can fund audits, verification, insurance reserves, or dispute infrastructure without requiring the collateral itself to be native.", + "security_difference": "External collateral lacks reflexive upside from protocol growth and may not create the same long-term holder identity, but it provides deeper liquidity, clearer loss value, lower volatility for buyers, and simpler risk assessment." + }, + "native_token_removed_breaks": [ + "Native-token-denominated bonded status would not exist.", + "Endogenous token appreciation would no longer increase the cost of abandoning a supplier or machine identity.", + "Slashing would not directly reduce native-token supply or fund a token-denominated treasury.", + "Early bootstrap incentives based on native asset upside would be unavailable." + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens protocol-specific alignment and bootstrapping, but it does not break the compute escrow, verification, slashing, supplier admission, machine reputation, or dispute-resolution model. Those functions can operate with USDC or ETH collateral and protocol-native reputation records.", + "material_improvements_over_USDC_ETH": [ + "Native token can concentrate supplier and verifier stake into a protocol-specific asset whose value is tied to future network demand.", + "Native token can make reputation abandonment more expensive if bonded status appreciates with protocol growth.", + "Native token can create an endogenous security budget through slashing and treasury accrual without relying only on external collateral flows.", + "Native token may help bootstrap early verifier and supplier participation before fee volume is large enough to fund all security costs.", + "Native token can link machine identity, bonded status, and routing priority into a single economic credential across marketplaces." + ], + "native_asset_costs_and_risks": [ + "Token volatility makes required bond value unstable relative to stablecoin-denominated job losses.", + "Speculative demand may dominate real compute utility, weakening the relationship between token price and security needs.", + "Buyers and enterprises may prefer stablecoin escrow and predictable penalties over exposure to a native asset.", + "Native collateral adds liquidity, oracle, market manipulation, and liquidation-risk considerations absent from USDC bonds.", + "A native token may introduce regulatory, governance, and treasury complexity before the protocol proves fee-based demand.", + "If token price falls, security budget and slash deterrence can collapse exactly when confidence is needed most." + ], + "final_rationale": "TOKEN_OPTIONAL because ProofGrid has real token-shaped utility, but the protocol-specific property is not impossible to reproduce economically enough with ETH, USDC, or external collateral. The essential functions are slashable bonds, verifier accountability, machine reputation, routing priority, and security-budget funding; these can be implemented with stablecoin or ETH collateral while keeping reputation and machine identity native to the protocol database or contracts. A native token may moderately improve alignment, bootstrapping, and identity stickiness, but USDC or ETH is preferable because it gives buyers predictable collateral value, deeper liquidity, simpler compensation, and lower reflexive security risk despite some degradation in network-specific alignment.", + "red_team_flags": [ + "TOKEN_NOT_REQUIRED", + "YIELD_DEPENDENCY", + "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT" + ], + "final_ic_decision": "REVISE_TOKEN_MODEL", + "final_ic_score": 67.9, + "sol_final_ic_review": { + "score_adjustment": 4, + "decision": "REVISE_TOKEN_MODEL", + "rationale": "Repaired token-utility evidence shows credible token-shaped roles around slashable security bonds, verifier accountability, supplier admission, machine identity cost, and security-budget formation. However, the core weakness remains: these functions can be implemented substantially with USDC/ETH collateral plus protocol-native reputation, identity, and slashing records. Native-token removal causes only moderate degradation, not protocol failure. Demand, onchain escrow/verification need, network effects, and value-accrual design are strong, but token necessity is not strong enough for promotion. Best path is to validate the protocol and security model while revising away from a mandatory native-token thesis or proving why external collateral is insufficient." + } + } + ], "corrected_former_survivor_reviews": [ { "proposal_id": "0b8c4fa3-febf-4646-b750-eece96fd9379", @@ -131,7 +494,7 @@ "token_economy": "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.", "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.", "why_onchain": "The system materially benefits from onchain implementation because it is explicitly a neutral, cross-platform trust and reputation layer among competing marketplaces, vendors, payment processors, issuers, and agent operators. Onchain records can provide verifiable credential registries, revocation status, delegated authority, escrow/payment proofs, dispute outcomes, and tamper-resistant reputation references without requiring one marketplace or SaaS vendor to own the identity graph. Programmable guarantees are especially relevant for autonomous agents because permissions, payment limits, escrow conditions, and revocations can be machine-readable and enforceable across counterparties.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "The protocol has real collateral and slashing needs, but those needs are not native-token-specific. ETH, USDC, tokenized cash instruments, or insurance-backed collateral can economically reproduce the security model while improving price stability, liquidity, and institutional acceptance. The native token mainly adds captive value capture and bootstrapping optionality, not an essential protocol-specific property.", "token_role_decomposition": { "SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", @@ -170,8 +533,8 @@ "SECURITY_BOND", "SLASHABLE_COLLATERAL" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "A native token could concentrate economic upside around the clearinghouse, fund early security budgets, give providers a shared coordination asset, and create a unified stake/reward medium for trust providers and resolvers.", + "argument_against_native_token": "The core functions are identity, attestation aggregation, delegated authority records, dispute history, reputation, and slashable accountability. None require a proprietary asset; USDC, ETH, or other liquid collateral can provide the same bonding and slashing mechanics with lower volatility and higher counterparty confidence.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -182,17 +545,26 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], - "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "external_collateral_counterfactual": { + "description": "Trust providers, agents, and dispute resolvers post USDC, ETH, tokenized T-bills, insurance-backed guarantees, or venue-approved collateral into escrow contracts. Slashing, admission thresholds, credit limits, and dispute penalties operate the same way without requiring a native asset.", + "security_result": "Equivalent or better, because collateral value is more liquid, easier to price, less reflexive, and more acceptable to counterparties." + }, + "native_token_removed_breaks": [ + "No essential protocol function breaks.", + "Security bonds can be denominated in USDC, ETH, or other approved collateral.", + "Slashable resolver and trust-provider accountability remains intact.", + "Agent bonds and acceptance limits remain intact.", + "Usage fees and treasury revenue can accrue in stablecoins or fiat." + ], + "native_token_removed_degradation": "MINOR", + "native_token_removed_explanation": "Removing the native token may reduce speculative bootstrapping and captive value capture, but it does not materially impair trust attestations, resolver slashing, agent bonding, payment reputation, or credential records.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ "decentralized marketplace coordination", "proof/attestation markets" ], - "token_necessity_classification": "TOKEN_OPTIONAL", + "token_necessity_classification": "TOKEN_UNNECESSARY", "token_demand_loop": [ { "loop": "Permissionless trust provider loop", @@ -224,7 +596,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 18.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 82.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -262,8 +634,8 @@ "token_red_team_flags": [ "TOKEN_NOT_REQUIRED" ], - "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 74.3, + "crypto_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "crypto_ic_score": 62.3, "research": { "query_plan": { "USER_PAIN": [ @@ -2563,7 +2935,11 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": -8, + "decision": "REJECT_TOKEN_NOT_NEEDED", + "rationale": "Strong product and protocol thesis with real demand for agent identity, authority, attestations, reputation, dispute history, and delegated trust records. However, the repaired token utility evidence confirms the native token is not structurally necessary: the strongest roles are bonding, slashing, and security collateral, all of which are better served by ETH, USDC, tokenized cash instruments, insurance-backed guarantees, or venue-approved collateral. Native-token removal causes only minor degradation, mainly reducing speculative bootstrapping and captive value capture rather than impairing core protocol function. Component scores support this split: real usage demand, onchain necessity, value accrual quality, network effects, and security model are strong, but TOKEN_NECESSITY is very weak at 18 and the red-team flag is TOKEN_NOT_REQUIRED. This may be a high-quality venture or protocol business, but not a justified native token opportunity." + } }, { "proposal_id": "ace6f45b-84a9-4b91-9718-f2504c9da638", @@ -2584,7 +2960,7 @@ "token_economy": "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.", "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.", "why_onchain": "PatchBond materially benefits from onchain implementation because its core asset is a neutral, reusable, verifiable record of bonded remediation commitments, escrowed value, claim outcomes, and assessor decisions across many vendors, buyers, insurers, and researchers. Smart contracts can make bond funding, deadlines, payout rules, claim states, and historical performance tamper-evident and consistently enforceable without requiring buyers to trust PatchBond or individual vendors as the sole recordkeeper.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "PatchBond has real collateral and slashing needs, but the protocol-specific property is not strong enough to make a native token necessary. The core security function is an enforceable vendor bond with independent assessment and predictable payout conditions, which USDC, ETH, fiat escrow, bank guarantees, or insurance collateral can reproduce more credibly for enterprise procurement. Although removing the token moderately degrades bootstrapping, native provider admission, and treasury value capture, external collateral is preferable because buyers value payout certainty, liquidity, accounting simplicity, and legal enforceability more than native-token reflexive security.", "token_role_decomposition": { "SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", @@ -2623,8 +2999,8 @@ "SECURITY_BOND", "SLASHABLE_COLLATERAL" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "The strongest case for a native token is that PatchBond needs slashable, usage-linked collateral for vendors and assessors, and a native asset can coordinate provider admission, early network bootstrapping, treasury funding, and shared downside exposure in a single mechanism.", + "argument_against_native_token": "The strongest case against a native token is that the protocol's core product is credible remediation assurance for enterprise buyers, and that credibility is better served by liquid, stable, externally enforceable collateral such as USDC, ETH, fiat escrow, bank guarantees, or insurance-backed instruments.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -2635,10 +3011,18 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], - "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "external_collateral_counterfactual": { + "design": "Use USDC, ETH, fiat escrow, bank guarantees, or regulated insurance collateral for vendor bonds while charging protocol fees in stablecoin or fiat.", + "effect": "This preserves most buyer-facing trust, payout certainty, and procurement evidence while removing native-token volatility and liquidity risk." + }, + "native_token_removed_breaks": [ + "Native-token staking as the default provider admission mechanism", + "Direct native-token slashing into a protocol-controlled security budget", + "Token-denominated rewards for early assessors or infrastructure providers", + "Protocol treasury value capture through native-token demand" + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens native staking, bootstrapping incentives, and token-based treasury capture, but it does not break the core PatchBond workflow. Vendors can still post externally valuable collateral, assessors can still verify incidents, buyers can still compare bond histories, and claims can still be paid through stablecoin, ETH, fiat escrow, or insurance-backed structures.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ @@ -2663,7 +3047,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 48.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -2701,8 +3085,8 @@ "token_red_team_flags": [ "TOKEN_NOT_REQUIRED" ], - "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 73.6, + "crypto_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "crypto_ic_score": 66.4, "research": { "query_plan": { "USER_PAIN": [ @@ -4337,7 +4721,11 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": -6, + "decision": "REJECT_TOKEN_NOT_NEEDED", + "rationale": "PatchBond has a credible enterprise security-assurance market, strong real demand, good onchain standardization potential, and high-quality collateral/slashing workflows. However, the repaired token utility evidence explicitly classifies the token as TOKEN_OPTIONAL, flags TOKEN_NOT_REQUIRED, and shows the core buyer-facing value is better served by USDC, ETH, fiat escrow, bank guarantees, legal agreements, or insurance-backed collateral. Native-token removal causes only moderate degradation and does not break vendor bonds, assessor verification, buyer procurement evidence, or claims payouts. Strong collateral and slashing needs support a protocol, but not a volatile native asset. Do not promote to pilot or protocol validation as a tokenized crypto investment until the model removes or sharply limits the native token." + } }, { "proposal_id": "caacd3f6-10e6-412d-90f8-167557da235b", @@ -4358,7 +4746,7 @@ "token_economy": "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.", "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.", "why_onchain": "ProofGrid materially benefits from onchain implementation because the core product is a neutral, cross-organization verification and settlement layer for untrusted compute buyers, GPU suppliers, auditors, and verifiers. Onchain records can provide shared, tamper-evident job receipts, benchmark history, provider reputation, escrowed payments, dispute evidence, and programmable payout rules without requiring all participants to trust one marketplace operator. This is especially useful if ProofGrid aims to become infrastructure used across many compute marketplaces rather than a single managed platform.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "TOKEN_OPTIONAL because the native token may help bootstrap and coordinate a portable attestation network, but the core security model does not require it. ETH, USDC, or approved external collateral is preferable because slashing needs predictable, liquid, widely accepted value, while the protocol-specific properties such as machine identity, verifier reputation, routing eligibility, and dispute records can be represented as protocol state backed by external bonds. Any degradation from removing the token is mainly loss of endogenous value capture and bootstrap alignment, not loss of the attestation or slashing function itself.", "token_role_decomposition": { "SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "REQUIRED", @@ -4376,17 +4764,17 @@ "OTHER": "UNNECESSARY" }, "token_utility_scores": { - "SECURITY_UTILITY": 85, - "COORDINATION_UTILITY": 75, - "COLLATERAL_UTILITY": 85, - "SLASHING_UTILITY": 82, - "RESOURCE_ALLOCATION_UTILITY": 25, + "SECURITY_UTILITY": 45, + "COORDINATION_UTILITY": 50, + "COLLATERAL_UTILITY": 35, + "SLASHING_UTILITY": 40, + "RESOURCE_ALLOCATION_UTILITY": 20, "INCENTIVE_UTILITY": 25, - "NETWORK_BOOTSTRAP_UTILITY": 75, - "VALUE_CAPTURE_UTILITY": 75, - "MACHINE_ECONOMIC_UTILITY": 84, + "NETWORK_BOOTSTRAP_UTILITY": 55, + "VALUE_CAPTURE_UTILITY": 35, + "MACHINE_ECONOMIC_UTILITY": 50, "GOVERNANCE_UTILITY": 10, - "PAYMENT_UTILITY": 10, + "PAYMENT_UTILITY": 5, "SPECULATION_DEPENDENCE": 5 }, "strong_token_roles": [ @@ -4401,8 +4789,8 @@ "PROVIDER_ADMISSION", "MACHINE_ECONOMIC_IDENTITY" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "The best case for a native token is that ProofGrid is not merely a compute marketplace but a neutral cross-market security and reputation layer. A native asset could unify provider bonds, verifier bonds, machine identity, reputation portability, slashing, and security-budget funding under one endogenous incentive system.", + "argument_against_native_token": "The core trust problem is solved by attestations, reproducibility checks, dispute evidence, reputation records, and slashable collateral. None of these require the collateral to be a new volatile asset. USDC, ETH, or other liquid collateral can reproduce the economic security more cleanly and with less adoption friction.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -4413,10 +4801,20 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], - "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "external_collateral_counterfactual": { + "bond_asset": "USDC, ETH, tokenized T-bills, or approved liquid collateral", + "mechanism": "Providers and verifiers post external collateral into slashing contracts. Hardware attestations, job proofs, benchmark records, dispute evidence, and reputation remain protocol-native data objects, while economic penalties are denominated in liquid collateral.", + "security_result": "Fraud, SLA failure, lazy verification, and collusion remain slashable. Bond sizing can be risk-tiered by job value, hardware class, verifier history, and workload reproducibility without requiring a volatile native asset.", + "tradeoff": "The protocol loses some endogenous token demand and upside capture, but gains more predictable collateral value and lower buyer/provider friction." + }, + "native_token_removed_breaks": [ + "No core attestation function breaks; hardware proofs and job evidence can still be recorded.", + "No core slashing function breaks; providers and verifiers can post USDC, ETH, or approved collateral.", + "No core payment function breaks; settlement is already stablecoin-or-fiat oriented.", + "No core reputation function breaks; reputation can attach to identities and bonded records independent of collateral asset." + ], + "native_token_removed_degradation": "MINOR", + "native_token_removed_explanation": "Removing the native token modestly reduces endogenous token demand, speculative bootstrap incentives, and protocol-owned security-budget capture. It does not materially impair provider admission, verifier bonding, machine identity, dispute resolution, or risk-tiered collateral because those mechanisms can be implemented with external collateral and protocol-native records.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ @@ -4473,7 +4871,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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\u00e2\u20ac\u2122s baseline cloud option.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 42.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -4512,7 +4910,7 @@ "TOKEN_NOT_REQUIRED" ], "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 71.5, + "crypto_ic_score": 63.6, "research": { "query_plan": { "USER_PAIN": [ @@ -6151,7 +6549,11 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": -6, + "decision": "REJECT_TOKEN_UTILITY_WEAK", + "rationale": "Repaired token utility evidence confirms the core protocol is credible but the native token remains optional. Attestation records, verifier accountability, dispute evidence, provider admission, machine reputation, and slashing can be implemented with protocol state plus external collateral such as USDC, ETH, or tokenized T-bills. Native-token removal causes only MINOR degradation, mostly reducing endogenous value capture and bootstrap alignment rather than breaking security or utility. Strong component scores for demand, onchain necessity, value accrual design, network effects, tokenomics, and security do not overcome the red-team TOKEN_NOT_REQUIRED flag or the low token-necessity score. Do not advance as a crypto/token finalist unless the model is revised around external collateral or a materially stronger unavoidable native-token role." + } }, { "proposal_id": "acb07824-7217-4253-a1d7-1f5122c4fd9b", @@ -6172,7 +6574,7 @@ "token_economy": "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.", "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.", "why_onchain": "ProofBond materially benefits from being onchain because its core asset is portable, neutral, cross-platform trust backed by economic guarantees. Bonds, attestations, verifier records, claim histories, slashing or payout conditions, and machine identities are more credible when they are not controlled by a single SaaS provider or marketplace. Onchain escrow and programmable settlement can make machine reputation economically accountable, composable across buyers, and usable by other agents or platforms without bilateral integrations.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "ProofBond has real collateral and slashing needs, but the protocol-specific property claimed for the native token can be reproduced economically enough with ETH, USDC, or other external collateral. Portable machine reputation, verifier staking, dispute slashing, provider admission, and routing priority can all be implemented using external collateral plus non-transferable machine credentials and contract-enforced penalties. Although removing the native token causes moderate degradation in endogenous alignment, fee capture, and bootstrapping flexibility, ETH and especially USDC are preferable for the core guarantee because they are more liquid, more legible to buyers, less volatile, and provide clearer compensation value when claims fail.", "token_role_decomposition": { "SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", @@ -6190,18 +6592,18 @@ "OTHER": "USEFUL" }, "token_utility_scores": { - "SECURITY_UTILITY": 85, - "COORDINATION_UTILITY": 75, - "COLLATERAL_UTILITY": 85, - "SLASHING_UTILITY": 82, - "RESOURCE_ALLOCATION_UTILITY": 82, + "SECURITY_UTILITY": 62, + "COORDINATION_UTILITY": 55, + "COLLATERAL_UTILITY": 45, + "SLASHING_UTILITY": 52, + "RESOURCE_ALLOCATION_UTILITY": 50, "INCENTIVE_UTILITY": 25, - "NETWORK_BOOTSTRAP_UTILITY": 75, - "VALUE_CAPTURE_UTILITY": 75, - "MACHINE_ECONOMIC_UTILITY": 84, + "NETWORK_BOOTSTRAP_UTILITY": 48, + "VALUE_CAPTURE_UTILITY": 42, + "MACHINE_ECONOMIC_UTILITY": 58, "GOVERNANCE_UTILITY": 10, - "PAYMENT_UTILITY": 10, - "SPECULATION_DEPENDENCE": 5 + "PAYMENT_UTILITY": 8, + "SPECULATION_DEPENDENCE": 35 }, "strong_token_roles": [ "SECURITY_BOND", @@ -6218,8 +6620,8 @@ "RESOURCE_ALLOCATION", "MACHINE_ECONOMIC_IDENTITY" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "A native token gives ProofBond a unified economic identity and staking layer: machine operators, verifiers, and reviewers all hold slashable exposure to the same network whose reputation they secure, while fee-driven value capture can support a dedicated security budget and long-term participant alignment.", + "argument_against_native_token": "The essential security primitive is not a native asset; it is credible, liquid, slashable collateral backing measurable machine-performance claims. USDC or ETH can provide equal or better compensation certainty with lower volatility, simpler onboarding, and less speculative distortion.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -6230,10 +6632,24 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], - "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "external_collateral_counterfactual": { + "accepted_collateral": [ + "USDC", + "ETH", + "liquid staking tokens", + "tokenized treasury assets where legally and operationally appropriate" + ], + "mechanism": "Capability claims are bonded with external collateral, slashed for failed claims or malicious verification, and linked to machine identities through non-transferable credentials and historical performance records.", + "why_viable": "ProofBond mainly needs credible collateral, objective measurement, dispute resolution, and portable reputation. These are enforceable with external assets and do not require a proprietary monetary asset." + }, + "native_token_removed_breaks": [ + "direct native-token demand loop from operator bonding", + "single proprietary asset for verifier staking and assignment rights", + "native-token-based security budget design", + "direct treasury value capture from mandatory bond demand" + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens protocol-native alignment and value capture, but it does not break the core product. Operators can still bond claims, verifiers can still stake, disputes can still slash collateral, and buyers can still route work based on bonded track records using USDC or ETH collateral.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ @@ -6260,7 +6676,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 54.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 78.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -6299,7 +6715,7 @@ "TOKEN_NOT_REQUIRED" ], "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 73.0, + "crypto_ic_score": 64.3, "research": { "query_plan": { "USER_PAIN": [ @@ -7937,7 +8353,11 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": -8, + "decision": "REJECT_TOKEN_UTILITY_WEAK", + "rationale": "ProofBond has a credible crypto-relevant market and strong demand/onchain components, but the repaired token utility evidence confirms the native token is optional rather than necessary. The core functions, including bonding machine claims, verifier staking, dispute slashing, provider admission, routing priority, and portable reputation, can be implemented with USDC/ETH collateral plus non-transferable machine credentials. Red-team flag TOKEN_NOT_REQUIRED is decisive: native token removal causes only moderate degradation and does not break the protocol. Do not advance as a token finalist despite otherwise strong product and protocol scores." + } }, { "proposal_id": "9bffcfb7-01b9-4cb8-85a4-09308417930f", @@ -7958,7 +8378,7 @@ "token_economy": "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.", "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.", "why_onchain": "Onchain implementation could materially improve this system if the network is coordinating many independent compute, robotics, and edge-inference providers who do not fully trust one another. The strongest onchain case is neutral settlement, escrowed payments, programmable SLA guarantees, auditable usage records, permissionless provider onboarding, and machine-to-machine purchasing of capacity. Buyers and autonomous agents could reserve capacity, lock funds, verify telemetry or attestations, and settle automatically based on observed uptime, latency, location, or execution proofs. This matters more if the network becomes cross-organization and global rather than a managed marketplace with manually vetted providers.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "The token is strongly justified but not essential. The protocol-specific property that cannot be reproduced economically enough with ETH, USDC, or generic external collateral is the combination of persistent bonded machine identity, reputation-linked earning capacity, risk-proportional native lockup, and slashing that recapitalizes a protocol-native security budget. External collateral can reproduce financial penalties, but it does not create the same endogenous accountability layer where compute capacity, routing, verification, and machine reputation are all secured by stake whose value and opportunity cost are tied to the network itself.", "token_role_decomposition": { "SECURITY_BOND": "REQUIRED", "SLASHABLE_COLLATERAL": "REQUIRED", @@ -8004,8 +8424,8 @@ "RESOURCE_ALLOCATION", "MACHINE_ECONOMIC_IDENTITY" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "A native token is strongly justified if the network wants machine identities, providers, verifiers, and solvers to post protocol-specific slashable stake that persists across jobs and directly links reputation, admission, routing power, and security budget to the health of the compute clearance network.", + "argument_against_native_token": "Most payment, settlement, and compensation functions can be performed more cleanly with USDC, ETH, or other external collateral, and stable collateral is often better for predictable buyer protection than a volatile native token.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -8016,16 +8436,36 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], + "external_collateral_counterfactual": { + "description": "The protocol could accept USDC, ETH, or liquid staking tokens as provider, verifier, and solver collateral. This would likely improve collateral stability and user familiarity, but it would make the accountability layer more generic and less coupled to machine identity, reputation, network-specific risk, and protocol security budget formation.", + "advantages": [ + "Lower volatility for collateral denominated in USDC", + "Better liquidity and easier risk management", + "Less reflexive collapse risk during protocol stress", + "Simpler buyer/provider onboarding" + ], + "limitations": [ + "Collateral demand would not create protocol-native economic lockup proportional to compute-network risk", + "Machine identities would be secured by rented external capital rather than by a protocol-specific stake whose value is linked to long-term network trust", + "Slashing external collateral compensates victims but does not directly increase native security alignment or make reputation capital harder to port away", + "External collateral can reproduce financial penalty but not as cleanly reproduce token-denominated admission, reputation, and security-budget coupling" + ] + }, + "native_token_removed_breaks": [ + "Native risk-proportional token lockup tied to active service commitments", + "Protocol-native machine economic identity secured by continued staking", + "Direct coupling between reputation, admission, earning capacity, and native collateral", + "Slashing-driven recapitalization of native security or insurance pools", + "Token-based solver, verifier, and provider accountability across repeated interactions" + ], "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "native_token_removed_explanation": "Removing the native token would not break the compute marketplace or SLA settlement entirely because USDC, ETH, or other collateral could still support payments, bonds, and slashing. However, it would materially degrade the protocol-specific accountability layer by turning provider, verifier, solver, and machine commitments into generic collateral deposits rather than persistent native economic identities tied to reputation, admission, routing power, and the network security budget.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ "protocol fee settlement" ], - "token_necessity_classification": "TOKEN_OPTIONAL", + "token_necessity_classification": "TOKEN_STRONGLY_JUSTIFIED", "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." @@ -8057,7 +8497,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 78.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 72.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -8092,11 +8532,9 @@ "Native-token-removed asks whether protocol becomes materially worse, not literally impossible." ] }, - "token_red_team_flags": [ - "TOKEN_NOT_REQUIRED" - ], - "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 72.3, + "token_red_team_flags": [], + "crypto_ic_decision": "PROTOCOL_VALIDATE", + "crypto_ic_score": 79.7, "research": { "query_plan": { "USER_PAIN": [ @@ -9703,7 +10141,11 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": 2, + "decision": "PROTOCOL_VALIDATE", + "rationale": "Repaired token utility evidence supports a materially stronger native-token case than a generic compute marketplace: slashable protocol-native collateral tied to machine identity, reputation, routing power, verifier accuracy, provider admission, and security budget formation is a coherent utility thesis. Component scores are strong on value accrual, tokenomics sustainability, real demand, network effects, and security model, with no red-team flags. However, the token remains not strictly essential because external collateral can cover payments, bonds, and some slashing, and bootstrappability plus autonomous operability are only moderate. This warrants validation of protocol mechanics, SLA observability, slashing objectivity, and supply/demand liquidity before any higher-conviction pilot." + } }, { "proposal_id": "1a87f3a4-1fdd-4d6f-89e6-80305aa4c818", @@ -9724,7 +10166,7 @@ "token_economy": "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.", "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.", "why_onchain": "ProofGrid materially benefits from onchain implementation because its core value proposition depends on neutral escrow, verifiable completion records, programmable payment release, cross-marketplace supplier reputation, and trust minimization between buyers, GPU providers, and verification nodes that may not share a common operator. Onchain rails make the settlement and dispute state auditable, reduce reliance on a single SaaS intermediary, and allow multiple compute marketplaces or autonomous agents to coordinate around the same escrow and reputation layer.", - "why_token": "Token score derives from structural utility, not native payment currency alone.", + "why_token": "TOKEN_OPTIONAL because ProofGrid has real token-shaped utility, but the protocol-specific property is not impossible to reproduce economically enough with ETH, USDC, or external collateral. The essential functions are slashable bonds, verifier accountability, machine reputation, routing priority, and security-budget funding; these can be implemented with stablecoin or ETH collateral while keeping reputation and machine identity native to the protocol database or contracts. A native token may moderately improve alignment, bootstrapping, and identity stickiness, but USDC or ETH is preferable because it gives buyers predictable collateral value, deeper liquidity, simpler compensation, and lower reflexive security risk despite some degradation in network-specific alignment.", "token_role_decomposition": { "SECURITY_BOND": "STRONGLY_USEFUL", "SLASHABLE_COLLATERAL": "STRONGLY_USEFUL", @@ -9764,8 +10206,8 @@ "SECURITY_BOND", "SLASHABLE_COLLATERAL" ], - "argument_for_native_token": "", - "argument_against_native_token": "", + "argument_for_native_token": "ProofGrid has a credible native-token argument because its core problem is not payment but trust formation across independent GPU hosts, verifiers, marketplaces, and machine identities. A slashable native bond can bind suppliers and verifiers to portable reputation, make machine identity abandonment costly, and create an endogenous security budget for verification and disputes.", + "argument_against_native_token": "The same escrow, slashing, admission, and reputation mechanics can mostly be implemented with USDC or ETH collateral plus protocol-specific non-transferable reputation records. Compute buyers care about predictable compensation and verification quality, not exposure to a volatile protocol asset. Native-token volatility and speculation may reduce rather than improve security per dollar bonded.", "stablecoin_counterfactual": { "MODEL_A_native_payment_staking_governance": "baseline proposal", "MODEL_B_stablecoin_payment_native_bond": "preferred if payment utility is separable", @@ -9776,10 +10218,18 @@ "external_collateral_identical_security": false, "stable_collateral_identical_security": false }, - "external_collateral_counterfactual": {}, - "native_token_removed_breaks": [], - "native_token_removed_degradation": "MATERIAL", - "native_token_removed_explanation": "", + "external_collateral_counterfactual": { + "description": "Suppliers and verifiers could bond ETH, USDC, or a diversified external collateral basket while reputation, machine identity, routing priority, job history, and slashing logic remain protocol-specific non-transferable records. Escrows can remain in stablecoins. Slashed collateral can fund audits, verification, insurance reserves, or dispute infrastructure without requiring the collateral itself to be native.", + "security_difference": "External collateral lacks reflexive upside from protocol growth and may not create the same long-term holder identity, but it provides deeper liquidity, clearer loss value, lower volatility for buyers, and simpler risk assessment." + }, + "native_token_removed_breaks": [ + "Native-token-denominated bonded status would not exist.", + "Endogenous token appreciation would no longer increase the cost of abandoning a supplier or machine identity.", + "Slashing would not directly reduce native-token supply or fund a token-denominated treasury.", + "Early bootstrap incentives based on native asset upside would be unavailable." + ], + "native_token_removed_degradation": "MODERATE", + "native_token_removed_explanation": "Removing the native token weakens protocol-specific alignment and bootstrapping, but it does not break the compute escrow, verification, slashing, supplier admission, machine reputation, or dispute-resolution model. Those functions can operate with USDC or ETH collateral and protocol-native reputation records.", "native_token_removed_outcome": "Native token removal materially degrades security/reputation if required roles remain.", "native_token_removed_degrades_protocol": true, "token_utility": [ @@ -9837,7 +10287,7 @@ "guard_verdict": "PASS_FOR_TESTNET_DESIGN", "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.", "component_scores": { - "TOKEN_NECESSITY": 62, + "TOKEN_NECESSITY": 58.0, "REAL_USAGE_DEMAND": 80, "ONCHAIN_NECESSITY": 82.0, "VALUE_ACCRUAL_QUALITY": 96, @@ -9877,8 +10327,8 @@ "YIELD_DEPENDENCY", "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT" ], - "crypto_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", - "crypto_ic_score": 64.3, + "crypto_ic_decision": "REVISE_TOKEN_MODEL", + "crypto_ic_score": 67.9, "research": { "query_plan": { "USER_PAIN": [ @@ -11496,90 +11946,40 @@ }, "research_confidence": "EVIDENCE_INSUFFICIENT", "legal_review_required": true, - "corrected_review_scope": "former_v031_survivor_reprocessed_without_new_ideas" + "sol_final_ic_review": { + "score_adjustment": 4, + "decision": "REVISE_TOKEN_MODEL", + "rationale": "Repaired token-utility evidence shows credible token-shaped roles around slashable security bonds, verifier accountability, supplier admission, machine identity cost, and security-budget formation. However, the core weakness remains: these functions can be implemented substantially with USDC/ETH collateral plus protocol-native reputation, identity, and slashing records. Native-token removal causes only moderate degradation, not protocol failure. Demand, onchain escrow/verification need, network effects, and value-accrual design are strong, but token necessity is not strong enough for promotion. Best path is to validate the protocol and security model while revising away from a mandatory native-token thesis or proving why external collateral is insufficient." + } } ], "routed_to_saas": [ - { - "company": "Agent Passport Clearinghouse", - "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." - }, { "company": "PatchBond Network", "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." + "reason": "V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral." }, { "company": "ProofGrid Compute Attestation Network", "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." + "reason": "V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral." }, { "company": "ProofBond", "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." - }, - { - "company": "Compute Clearance Network", - "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." + "reason": "V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral." }, { "company": "ProofGrid Compute Escrow", "token_classification": "TOKEN_OPTIONAL", - "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.", - "reason": "Corrected rejudge found native token utility insufficient after removing injected/speculative language." + "reason": "V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral." } ], - "research_health": { - "sources_accepted": 85, - "sources_rejected": 193 - }, "token_red_team_failures": { - "TOKEN_NOT_REQUIRED": 6, + "TOKEN_NOT_REQUIRED": 5, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 }, - "v02_v03_v031_comparison": { - "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_corrected": { - "raw": 20, - "onchain_passed": 11, - "onchain_rejected": 9, - "token_optional": 6, - "crypto_survivors": 0, - "finalists": 0 - } - }, - "stop_conditions": { - "token_sale": false, - "nft_sale": false, - "founding_membership_sale": false, - "fundraising": false, - "mainnet_issuance": false, - "user_contact": false, - "real_spend": 0 - }, "v02_comparison": { "v02": { "raw": 30, @@ -11603,6 +12003,28 @@ "token_optional": 6, "crypto_survivors": 0, "finalists": 0 + }, + "v032b": { + "token_optional": 4, + "token_unnecessary": 1, + "token_strongly_justified": 1, + "token_essential": 0, + "crypto_survivors": 0, + "finalists": 0 } + }, + "research_health": { + "broad_research_redone": false + }, + "token_utility_distribution": {}, + "capability_gaps": [], + "stop_conditions": { + "token_sale": false, + "nft_sale": false, + "founding_membership_sale": false, + "fundraising": false, + "mainnet_issuance": false, + "user_contact": false, + "real_spend": 0 } } diff --git a/docs/crypto_venture_cohort_v031_20260816.md b/docs/crypto_venture_cohort_v031_20260816.md index 1a06586..7b68dd3 100644 --- a/docs/crypto_venture_cohort_v031_20260816.md +++ b/docs/crypto_venture_cohort_v031_20260816.md @@ -1,11 +1,11 @@ -# CRYPTO VENTURE COHORT V0.3.1 CORRECTED +# CRYPTO VENTURE COHORT V0.3.2B TOKEN JUDGE EVIDENCE REPAIR 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: `6`. Token strongly justified: `0`. Token essential: `0`. Duplicates: `0`. +Token unnecessary: `1`. Token optional/routed SaaS: `4`. Token strongly justified: `1`. Token essential: `0`. Duplicates: `0`. Crypto survivors: `0`. Autonomous crypto survivors: `0`. Assisted high-potential: `0`. Security-blocked: `0`. Finalists: `0`. Generation attempts: `20` @@ -41,10 +41,10 @@ Generation attempts: `20` "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": 6, + "token_unnecessary_rejections": 1, + "token_optional_route_to_saas": 4, "token_essential": 0, - "token_strongly_justified": 0, + "token_strongly_justified": 1, "serious_crypto_survivors": 0, "crypto_survivors": 0, "token_design_attempts": 11, @@ -65,7 +65,7 @@ Generation attempts: `20` "protocol_security_gate_blocked": 0, "protocol_security_gate_passed": 0, "token_red_team_failures": { - "TOKEN_NOT_REQUIRED": 6, + "TOKEN_NOT_REQUIRED": 5, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 }, @@ -92,6 +92,71 @@ Generation attempts: `20` "TOKEN_NOT_REQUIRED": 6, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 + }, + "v032b_existing_six_token_judge": 6, + "v032b_existing_six_red_team": 6, + "v032b_existing_six_final_ic": 6, + "v032b_before_after_classifications": [ + { + "company": "Agent Passport Clearinghouse", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_UNNECESSARY", + "score": 18.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 62.3 + }, + { + "company": "PatchBond Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 48.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_NOT_NEEDED", + "final_ic_score": 66.4 + }, + { + "company": "ProofGrid Compute Attestation Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 42.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 63.6 + }, + { + "company": "ProofBond", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 54.0, + "required_field_gaps": [], + "final_ic_decision": "REJECT_TOKEN_UTILITY_WEAK", + "final_ic_score": 64.3 + }, + { + "company": "Compute Clearance Network", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_STRONGLY_JUSTIFIED", + "score": 78.0, + "required_field_gaps": [], + "final_ic_decision": "PROTOCOL_VALIDATE", + "final_ic_score": 79.7 + }, + { + "company": "ProofGrid Compute Escrow", + "before": "TOKEN_OPTIONAL", + "after": "TOKEN_OPTIONAL", + "score": 58.0, + "required_field_gaps": [], + "final_ic_decision": "REVISE_TOKEN_MODEL", + "final_ic_score": 67.9 + } + ], + "v032b_required_field_gaps": 0, + "v032b_token_red_team_failures": { + "TOKEN_NOT_REQUIRED": 5, + "YIELD_DEPENDENCY": 1, + "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 } } ``` @@ -116,20 +181,37 @@ Generation attempts: `20` Fewer than 3 qualified; weak token ideas were not promoted. +## V0.3.2B Before/After + +- Agent Passport Clearinghouse: `TOKEN_OPTIONAL` -> `TOKEN_UNNECESSARY`. Score: `18.0`. Final IC: `REJECT_TOKEN_NOT_NEEDED` at `62.3`. + Required field gaps: none + Final rationale: The protocol has real collateral and slashing needs, but those needs are not native-token-specific. ETH, USDC, tokenized cash instruments, or insurance-backed collateral can economically reproduce the security model while improving price stability, liquidity, and institutional acceptance. The native token mainly adds captive value capture and bootstrapping optionality, not an essential protocol-specific property. +- PatchBond Network: `TOKEN_OPTIONAL` -> `TOKEN_OPTIONAL`. Score: `48.0`. Final IC: `REJECT_TOKEN_NOT_NEEDED` at `66.4`. + Required field gaps: none + Final rationale: PatchBond has real collateral and slashing needs, but the protocol-specific property is not strong enough to make a native token necessary. The core security function is an enforceable vendor bond with independent assessment and predictable payout conditions, which USDC, ETH, fiat escrow, bank guarantees, or insurance collateral can reproduce more credibly for enterprise procurement. Although removing the token moderately degrades bootstrapping, native provider admission, and treasury value capture, external collateral is preferable because buyers value payout certainty, liquidity, accounting simplicity, and legal enforceability more than native-token reflexive security. +- ProofGrid Compute Attestation Network: `TOKEN_OPTIONAL` -> `TOKEN_OPTIONAL`. Score: `42.0`. Final IC: `REJECT_TOKEN_UTILITY_WEAK` at `63.6`. + Required field gaps: none + Final rationale: TOKEN_OPTIONAL because the native token may help bootstrap and coordinate a portable attestation network, but the core security model does not require it. ETH, USDC, or approved external collateral is preferable because slashing needs predictable, liquid, widely accepted value, while the protocol-specific properties such as machine identity, verifier reputation, routing eligibility, and dispute records can be represented as protocol state backed by external bonds. Any degradation from removing the token is mainly loss of endogenous value capture and bootstrap alignment, not loss of the attestation or slashing function itself. +- ProofBond: `TOKEN_OPTIONAL` -> `TOKEN_OPTIONAL`. Score: `54.0`. Final IC: `REJECT_TOKEN_UTILITY_WEAK` at `64.3`. + Required field gaps: none + Final rationale: ProofBond has real collateral and slashing needs, but the protocol-specific property claimed for the native token can be reproduced economically enough with ETH, USDC, or other external collateral. Portable machine reputation, verifier staking, dispute slashing, provider admission, and routing priority can all be implemented using external collateral plus non-transferable machine credentials and contract-enforced penalties. Although removing the native token causes moderate degradation in endogenous alignment, fee capture, and bootstrapping flexibility, ETH and especially USDC are preferable for the core guarantee because they are more liquid, more legible to buyers, less volatile, and provide clearer compensation value when claims fail. +- Compute Clearance Network: `TOKEN_OPTIONAL` -> `TOKEN_STRONGLY_JUSTIFIED`. Score: `78.0`. Final IC: `PROTOCOL_VALIDATE` at `79.7`. + Required field gaps: none + Final rationale: The token is strongly justified but not essential. The protocol-specific property that cannot be reproduced economically enough with ETH, USDC, or generic external collateral is the combination of persistent bonded machine identity, reputation-linked earning capacity, risk-proportional native lockup, and slashing that recapitalizes a protocol-native security budget. External collateral can reproduce financial penalties, but it does not create the same endogenous accountability layer where compute capacity, routing, verification, and machine reputation are all secured by stake whose value and opportunity cost are tied to the network itself. +- ProofGrid Compute Escrow: `TOKEN_OPTIONAL` -> `TOKEN_OPTIONAL`. Score: `58.0`. Final IC: `REVISE_TOKEN_MODEL` at `67.9`. + Required field gaps: none + Final rationale: TOKEN_OPTIONAL because ProofGrid has real token-shaped utility, but the protocol-specific property is not impossible to reproduce economically enough with ETH, USDC, or external collateral. The essential functions are slashable bonds, verifier accountability, machine reputation, routing priority, and security-budget funding; these can be implemented with stablecoin or ETH collateral while keeping reputation and machine identity native to the protocol database or contracts. A native token may moderately improve alignment, bootstrapping, and identity stickiness, but USDC or ETH is preferable because it gives buyers predictable collateral value, deeper liquidity, simpler compensation, and lower reflexive security risk despite some degradation in network-specific alignment. + ## Routed To SaaS -- Agent Passport Clearinghouse: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. - PatchBond Network: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. + V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral. - ProofGrid Compute Attestation Network: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. + V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral. - ProofBond: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. -- Compute Clearance Network: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. + V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral. - ProofGrid Compute Escrow: `TOKEN_OPTIONAL` - Corrected rejudge found native token utility insufficient after removing injected/speculative language. + V0.3.2B strict token judge evidence repair; native token not sufficiently justified versus ETH/USDC/external collateral. ## V0.2 Comparison @@ -157,6 +239,14 @@ Fewer than 3 qualified; weak token ideas were not promoted. "token_optional": 6, "crypto_survivors": 0, "finalists": 0 + }, + "v032b": { + "token_optional": 4, + "token_unnecessary": 1, + "token_strongly_justified": 1, + "token_essential": 0, + "crypto_survivors": 0, + "finalists": 0 } } ``` @@ -164,7 +254,7 @@ Fewer than 3 qualified; weak token ideas were not promoted. ## Token Red Team Failures { - "TOKEN_NOT_REQUIRED": 6, + "TOKEN_NOT_REQUIRED": 5, "YIELD_DEPENDENCY": 1, "SLASHING_DEPENDS_ON_HUMAN_JUDGMENT": 1 } @@ -172,8 +262,7 @@ Fewer than 3 qualified; weak token ideas were not promoted. ## Research Health { - "sources_accepted": 85, - "sources_rejected": 193 + "broad_research_redone": false } ## Token Utility Distribution diff --git a/tests/test_crypto_venture_cohort.py b/tests/test_crypto_venture_cohort.py index 7982a71..f214a6c 100644 --- a/tests/test_crypto_venture_cohort.py +++ b/tests/test_crypto_venture_cohort.py @@ -216,7 +216,7 @@ def test_v03_independent_counterfactual_native_removed_fields() -> None: assert token.metadata["independent_token_utility_judge"] == "CRYPTO_TOKEN_UTILITY_JUDGE" assert token.metadata["native_token_removed_degradation"] == "MATERIAL" assert token.metadata["argument_for_native_token"] - for field in ["argument_for_native_token", "argument_against_native_token", "external_collateral_counterfactual", "native_token_removed_breaks", "native_token_removed_explanation", "material_improvements_over_USDC_ETH", "native_asset_costs_and_risks"]: + for field in ["argument_for_native_token", "argument_against_native_token", "external_collateral_counterfactual", "native_token_removed_breaks", "native_token_removed_explanation", "material_improvements_over_USDC_ETH", "native_asset_costs_and_risks", "final_rationale"]: assert token.metadata[field] assert token.rationale