dual-trust-threshold-mapping

name	dual-trust-threshold-mapping
description	When adoption stalls, diagnose whether users are being asked to make two separate trust decisions at once before defaulting to "more marketing." Dual high-friction trust thresholds compound exponentially, not linearly — no tactical fix will work until one burden is eliminated.
composition_level	atom
extraction-lens	principle
source_attribution	Hivemind Library (attribution gap in source — flagged)
license	pending-consent
status	candidate

Dual Trust Threshold Mapping

When to use

• Adoption stalling despite solid product signals
• High CAC despite strong content / community
• Products handling sensitive infrastructure (funds, identity, custody)
• Products requiring long-term conviction in something volatile (assets, ecosystems, regulatory regimes)

When NOT to use

• Single-trust-decision products (e.g., simple SaaS in established category)
• Adoption stall clearly driven by product quality, not trust
• Already-validated products with clear PMF

Core procedure

Step 1: Map the two trust thresholds explicitly

• Intermediary trust — what is the user trusting the product/team to do safely?

  Example: "Trust this small startup with my wallet recovery keys."

• System conviction — what must the user believe will remain valuable or true over time?

  Example: "Believe crypto will still be a meaningful asset class in 20 years."

Step 2: Score each threshold (Low / Medium / High)

• Either Low → adoption friction is normal, standard tactics apply
• Both High → double trust burden, no tactic alone will fix it

The exponential nature of dual high-friction trust is the key insight — adoption doesn't get 2× harder, it gets exponentially harder.

Step 3: Pick one threshold to remove

• Eliminate intermediary trust via architecture: self-custody, non-custodial design, verifiable guarantees
• Borrow intermediary trust via distribution: regulated partners, banks, exchanges, legal firms
• Reduce long-horizon conviction: narrow the promise, shorter time-to-value, clearer immediate use case

Step 4: Failure mode of the diagnostic

If one barrier is already solved by regulation, established institutions, or accepted infrastructure, users effectively experience only one trust decision — don't force-fit the diagnostic. The skill applies when both thresholds are genuinely live.

Anchor example

Bifrost (failure case):

• Intermediary trust: small startup managing inheritance wallet keys (HIGH)
• System conviction: crypto will remain valuable enough to plan estates around long-term (HIGH during 2022 downturn)
• Both high simultaneously → adoption collapsed despite product quality

Output format

INTERMEDIARY TRUST: [what user trusts product to do]
- Score: Low | Medium | High

SYSTEM CONVICTION: [what user must believe long-term]
- Score: Low | Medium | High

DIAGNOSIS: single trust | double trust burden

IF DOUBLE BURDEN:
- Removable threshold: intermediary | conviction
- Removal mechanism: architecture | distribution | narrowed promise
- Specific change: [structural recommendation]

Failure modes

• Forcing the diagnostic when only one threshold is high. Some adoption stalls are just product quality. Apply judgment.
• Treating "more marketing" as the answer. Tactical fixes can't compensate for exponential trust friction.
• Removing both thresholds. Usually impossible without removing what makes the product unique. Pick one.

Related skills

• incentive-surface-diagnostic — pairs with this when adoption stall is in a token-driven product
• launch-mode-decision — visibility timing affects when the trust thresholds become visible
• costly-signal-credibility-check — costly signals can substitute for trust in some cases