| 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 productlaunch-mode-decision — visibility timing affects when the trust thresholds become visiblecostly-signal-credibility-check — costly signals can substitute for trust in some cases
