Hermes skill blockchain philosophy audit

blockchain-philosophy-audit

Audit a crypto/web3/blockchain project as a practical analyst: collect evidence, test decentralization claims, find hidden centralization, and produce a concise verdict.

Derived from Vladimir Popov’s “Блокчейн философия. Часть I” and selected DAO/legal-risk material from “Криптофшор” as transformed methodology only: do not quote or store long source passages.

Operating rule

Do not ask the user to provide sources. If the project name, ticker, URL, or contract is enough to identify the target, proceed.

Default to a deep/full audit on every /bf invocation. Do not choose a lazy quick scan just because the user phrased the request briefly. Run the full evidence-gathering workflow, check all core audit axes, and only compress the final wording if the chat context requires brevity. The analysis itself must remain deep.

Ask only one concise blocking question when:

• the target project is ambiguous and multiple unrelated projects match;
• the user asks for an investment/trading decision with missing risk constraints;
• external login/private community access is required.

Evidence discipline from project-audit workflow

When the target includes a URL or canonical domain, start with a domain-first pass:

• extract concrete facts from the target domain and official links discovered from it before broad web synthesis;
• lock the analysis to the canonical domain and its verified official properties;
• do not silently substitute a similar ticker, slug, brand, or alternate TLD;
• treat similar domains as non-official unless the canonical domain explicitly confirms them;
• if sources conflict, show the conflict and prefer “unverified” over a guessed conclusion.

Source confidence rules:

• primary sources first: official site/docs/blog, governance pages, contracts, audits, explorers, GitHub, official dashboards;
• analytics sources next: DefiLlama, Token Terminal, Dune, Tokenomist, CryptoRank, CoinGecko/CoinMarketCap, Messari, or equivalents;
• social/marketing sources are low-confidence support only and must not be the only basis for claims about traction, usage quality, adoption, valuation, or decentralization;
• exclude clearly mismatched sources from the final source list.

Default workflow

1. Identify target

   • Resolve project name, ticker, official site, chain/ecosystem, token, contracts, docs, GitHub, governance, explorers.
   • If ambiguous, report candidates and ask which one.

2. Gather evidence first

   • For fast/current search, use perplex or web search.
   • For crypto-specific market/on-chain/docs discovery, use /surf workflow.
   • For complex or disputed research, use /deep workflow.
   • Read references/research-protocol.md when source collection is non-trivial.

3. Build source map

   • Official: site, docs, whitepaper/litepaper, blog, roadmap.
   • Technical: GitHub, contracts, audits, clients/nodes, explorers.
   • Economic: token distribution, vesting, treasury, TVL, revenue/fees, liquidity, funds-use percentages, token sale terms.
   • Governance: DAO/forum, Snapshot/Tally, multisig, proposal history.
   • DAO/legal: entity/foundation/DAO boundaries, Terms, treasury custody, contributor/investor rights, liability signals.
   • Social/external: community, incidents, criticism, independent research, news.

4. Check fundamentals and traction

   • TVL, users, active wallets, volume, fees, revenue/earnings, liquidity, and trend when applicable.
   • Revenue source: trading fees, borrow/lend spread, staking yield, bribes, vault fees, emission-driven incentives, or other mechanism.
   • Usage quality: real usage / mixed / incentive-skewed / unclear / unverified.
   • Repeatable demand: recurring user behavior, embedded workflow, durable integrations, or not established.
   • Concentration dependencies: chain, key partner/integrator, dominant use case, critical infrastructure provider.
   • If reliable metrics are missing, write Traction unverified or Revenue unverified; do not infer growth from X posts, quests, campaigns, followers, or marketing.

5. Apply audit lenses

   • Decentralization and control.
   • User sovereignty and custody.
   • Governance reality vs governance theatre.
   • Tokenomics sanity.
   • Tokenization sanity and numeric fund-distribution heuristics.
   • Community ownership vs consumer packaging.
   • DAO/legal structure risk: true DAO vs legal wrapper, treasury accountability, Terms/user-flow exposure.
   • Useful work vs speculation.
   • Censorship/regulatory/provider dependency.
   • See references/audit-framework.md, references/red-flags.md, references/tokenization-tokenomics.md, references/dao-legal-risk.md, and references/bzx-case.md.

6. Check code, security, and external trust assumptions

   • Is core code open, active, and mapped to the live product/contracts?
   • Are audits present, current, and covering the critical modules?
   • Which critical components are closed, unaudited, or only described in docs?
   • If the project depends on bridge, messaging layer, oracle, relayer, verifier set, validator set, sequencer, custody, offchain operator, hosted frontend, RPC, or indexer, state the added trust assumptions.
   • Explicitly check for single operator / single signer / single verifier / single relayer / single node / 1-of-1 threshold / weak multisig patterns.
   • Distinguish safety risk (loss of funds, broken accounting, invalid minting, broken security guarantees) from liveness risk (halts, stuck withdrawals, delays, degraded operation).

7. Token market and valuation stance, if applicable

   • Include market cap, FDV, circulating supply, float/liquidity quality, unlock pressure, and peer context only when data is current and sufficient.
   • Use labels: cheap / fair / rich / unverified / not applicable.
   • Frame this as analytical asset-structure assessment, not investment advice or price prediction.
   • Default to unverified or not applicable when token data is absent, stale, or incomplete.

8. Score with caveats

   • Use qualitative levels, not fake precision:
     • strong / moderate / weak / unknown.
   • Mark evidence confidence:
     • high = official + independently verifiable;
     • medium = credible source but not independently confirmed;
     • low = claims, marketing, social chatter, or stale data.

9. Return final result

   • Default language: Russian.
   • Keep concise unless user asks for deep report.
   • Avoid Telegram markdown tables; use lists.
   • Include sources as named links/URLs where possible.
   • Use references/output-format.md.
   • For full audits, include a compact bull case, bear case, and “what would change the view” section.
   • When the user asks to turn an audit into a public social post, also use references/audit-to-social-post.example.md for a generic evidence-safe structure.

Modes

Non-negotiable: /bf is a deep-audit skill. There is no lazy/shallow mode. Short user phrasing may change only the final answer length, not the depth of research.

Specialized modes below are focus lenses inside the deep audit, not replacements for the full evidence workflow.

Full audit — default mode

Use for every /bf invocation, including short requests like “стоит смотреть?”, “быстро проверь”, “red flags”, “разбери проект”, “аудит”, “deep audit”, “исследуй”.

Output:

• verdict;
• evidence map;
• decentralization score by axis;
• tokenomics/tokenization/governance/community/DAO-legal analysis;
• traction/fundamentals and usage-quality analysis;
• code/security and external-infrastructure trust assumptions;
• token market/valuation stance when applicable;
• risks;
• unknowns;
• bull case, bear case, and what would change the assessment;
• next research actions.

Decentralization check

Use as the main focus lens when the question is specifically about whether a project is truly decentralized, while still running the deep evidence workflow.

Focus on:

• validators/nodes/miners/stakers;
• upgrade keys/admin keys;
• multisigs;
• permissionless participation;
• client diversity;
• hosting/provider dependencies;
• exit/fork ability.

Tokenomics sanity

Use as the main focus lens when the question is about token value, distribution, emissions, unlocks, treasury, or speculation, while still running the deep evidence workflow.

Focus on:

• utility vs extraction;
• whether the token is necessary or mostly a fundraising wrapper;
• funds-use percentages and numeric risk triggers from references/tokenization-tokenomics.md;
• insider allocation;
• vesting/unlocks;
• liquidity depth;
• revenue/fee capture;
• dependency on fiat benchmarks;
• incentives for users vs insiders.
• market cap, FDV, circulating supply, float/liquidity quality, and peer valuation only when evidence is current and sufficient;
• use Token valuation unverified or Token valuation not applicable rather than inventing a view.

Tokenization sanity

Use when the question is about whether the token itself makes sense, whether the project is a real tokenized economy, or whether a sale/ICO/DeFi design is mostly fundraising/speculation. Also run this as a compact pass inside every full audit.

Focus on:

• what exactly is tokenized: asset, right, access, reputation, work, governance, collateral, fee claim, or speculation;
• why a token is needed instead of points/equity/debt/subscription/database;
• funds-use percentages: team, advisors, marketing, bounty, development, liquidity, reserves;
• numeric heuristic triggers from references/tokenization-tokenomics.md;
• on-chain enforcement vs promises in docs;
• token needed / plausible but under-specified / fundraising wrapper / speculation engine / not enough data.

DAO/legal structure risk

Use when the question involves DAO design, DAO vs legal entity/foundation, treasury accountability, contributor/investor protection, Terms of Use, or liability exposure. Also run this as a compact pass inside every full audit when the project claims DAO/community governance.

Focus on:

• true DAO / legal entity + DAO / governance theatre / unclear wrapper classification;
• rights, duties, responsibility, and who can execute decisions;
• treasury/multisig controls, reporting, milestone release, and signer accountability;
• distribution of token, development, treasury, and governance power;
• investor/contributor mechanics: SAFT-like terms, lockers, vesting, wallets, refunds, delivery conditions;
• Terms acceptance and interface disclosure, especially click-wrap vs browse-wrap risk;
• sources: references/dao-legal-risk.md and references/bzx-case.md.

Guardrail: provide due-diligence/risk analysis only. Do not advise on tax evasion, hiding beneficial ownership, sanctions/KYC/AML bypass, or unlawful structuring. For real transactions, recommend a qualified lawyer in the relevant jurisdictions.

Community/governance reality

Use as the main focus lens when the question is about DAO, governance, community, or “is this owned by users?”, while still running the deep evidence workflow.

Focus on:

• proposal history;
• voter concentration;
• delegation power;
• forum quality;
• multisig signers;
• contributor paths;
• whether users are co-owners or consumers.

Self-check before replying

• Did I avoid lazy/shallow mode and run the deep audit workflow even if the user phrased the request briefly?
• Did I verify that I am analyzing the exact target/domain and not a similar project?
• Did I start with the canonical domain/official links when a URL was provided?
• Did I gather evidence instead of relying on project marketing?
• Did I distinguish official claims from verified facts?
• Did I avoid using social/marketing sources as proof of traction, adoption, valuation, or usage quality?
• Did I mark missing traction/revenue/valuation data as unverified instead of inferring growth?
• Did I check hidden centralization: upgrades, multisigs, validators, infrastructure, investors?
• Did I check external-infrastructure dependencies and split safety vs liveness risks where relevant?
• Did I check code openness, repo activity, audit coverage, and closed/unaudited critical modules?
• Did I include tokenization/tokenomics sanity in full audits, including numeric threshold triggers when data exists?
• Did I mark unknowns clearly?
• Did I avoid investment advice certainty?
• Did I avoid legal/tax/KYC bypass advice and frame DAO/legal findings as risk analysis?
• Did I include bull/bear/what-would-change for a full audit?
• Did I provide an actionable next step?

---

Hermes migration note