Get the blockchain architecture right before you build it.

Most blockchain projects fail because blockchain was chosen before the problem was understood.

The question "which blockchain should we use?" is premature until you have answered "does this problem require a blockchain at all?" A shared database with proper access controls solves 80% of the "we need a blockchain for transparency" use cases at 10% of the cost and complexity. The remaining 20% — cases where trustless operation across adversarial parties, immutable audit trails with no trusted administrator, or programmable money without a centralised counterparty genuinely matter — are the cases where blockchain is not just appropriate but necessary. PROPELOO starts every blockchain consulting engagement with this question. The answer shapes everything else.

What blockchain consulting covers.

System Layers

• Assessment Layer: Problem analysis, blockchain applicability assessment, build vs buy, chain selection
• Architecture Layer: System design, on-chain vs off-chain boundaries, data model, contract architecture
• Tokenomics Layer: Token model review, emission design, governance design, incentive analysis
• Security Layer: Threat modelling, attack surface analysis, audit preparation
• Delivery Layer: Technical roadmap, team structure recommendations, vendor evaluation

Core Technical Capabilities

• Blockchain Applicability Assessment

  Structured analysis of whether the problem genuinely requires blockchain — trustlessness requirements, number of adversarial parties, need for programmable settlement, regulatory considerations and total cost comparison vs centralised alternatives.

• Architecture Design

  End-to-end system architecture for blockchain projects — on-chain vs off-chain boundary definition, data availability strategy, indexing architecture, wallet integration approach and upgrade strategy.

• Chain Selection Advisory

  Objective evaluation of EVM chains (Ethereum, Arbitrum, Base, Polygon, BSC), Solana, Cosmos/IBC and application chains against specific requirements: throughput, finality, ecosystem, gas cost, developer tooling and regulatory acceptance.

• Tokenomics Review

  Independent review of token economic models — emission sustainability, value accrual mechanism, governance capture resistance, vesting schedule analysis and failure mode modelling under adverse market conditions.

• Smart Contract Design Advisory

  Architecture-level smart contract review before implementation — invariant definition, upgrade strategy selection, access control design, oracle architecture and economic attack surface identification.

• Team & Vendor Assessment

  Technical due diligence on blockchain development teams and vendors — code quality assessment, architecture review, security posture evaluation and delivery track record analysis.

How we think about blockchain consulting.

Honest consulting sometimes means telling a client their blockchain idea is not a blockchain problem. That conversation, delivered clearly and early, is more valuable than six months of building the wrong thing.

• Blockchain is a solution to specific problems

  Blockchain is appropriate when: multiple parties who do not trust each other need to agree on state without a trusted intermediary, settlement must be programmable and trustless, or immutability with no administrator override is a genuine requirement. For everything else — shared databases, audit trails managed by trusted parties, internal system integration — blockchain adds cost and complexity without proportional benefit.

  Axiom:

• Chain selection is a 10-year commitment

  Migrating a live smart contract to a different chain requires deploying new contracts, migrating state, updating all integrations and convincing users to migrate their assets. Choose the chain that will be the right choice in three years, not just the one with the highest hype today. Ecosystem stability, developer tooling quality and regulatory acceptance matter more than TPS benchmarks for most enterprise applications.

  Axiom:

• Tokenomics cannot be fixed after launch

  A token that launches with a flawed emission schedule, insufficient value sinks or a governance model vulnerable to capture cannot be fixed without a governance vote that may itself be captured. Tokenomics must be right before launch. The cost of getting it right (economics modelling, incentive analysis, attack scenario testing) is small compared to the cost of a failed protocol.

  Axiom:

• The audit is too late if it is the first security review

  Third-party audits find what is in the code. Security consulting before development finds what should not be in the code in the first place. Architecture-level security decisions — oracle design, upgrade mechanism, access control model — must be correct before a line of Solidity is written.

  Axiom:

The blockchain consulting engagement questions.

• Does this need blockchain at all?

  Impact: This is the first and most important question. A client who pays for an honest "no" saves 6-12 months of misdirected development.

  • Yes: trustless multi-party settlement, immutable audit, programmable money
  • No: shared database with access controls is sufficient
  • Maybe: some components benefit, others do not — hybrid approach
  • Unknown: assessment required before recommending

• Public blockchain vs private/consortium?

  Impact: Public chains for applications where permissionless access and external verifiability are genuine requirements. Private/consortium for enterprise applications where participant identity is known and regulatory constraints apply.

  • Public (Ethereum/Solana) — maximum trustlessness, permissionless, regulatory risk
  • Consortium (Hyperledger Fabric, Quorum) — permissioned, known validators, enterprise-grade privacy
  • Private (Besu) — full control, single-party benefit unclear vs database
  • Application chain (Cosmos SDK) — custom consensus, full control, operational burden

• EVM vs Solana vs Cosmos?

  Impact: EVM L2 (Arbitrum, Base) for most new DeFi and token applications — EVM compatibility with manageable gas costs. Solana for high-frequency trading or gaming where transaction throughput and cost are primary constraints.

  • EVM (Ethereum L1) — maximum ecosystem, highest gas cost, institutional credibility
  • EVM L2 (Arbitrum/Base/Optimism) — EVM compatibility, lower gas, growing ecosystem
  • Solana — high throughput, low cost, different programming model
  • Cosmos SDK — application-specific chain, IBC interoperability, highest operational burden

• Token or no token?

  Impact: Only introduce a token when it solves a specific coordination problem that cannot be solved without it. Tokens add regulatory complexity, require tokenomics design and introduce economic attack surfaces. Absent a specific need, avoid them.

  • Native token — enables governance, incentive alignment, regulatory complexity
  • Stablecoin only — simpler, less regulatory risk, limited incentive mechanisms
  • No token — pure smart contract system, no tokenomics complexity
  • Governance token only — no economic function, limited utility

• Build vs use existing protocol?

  Impact: Fork battle-tested protocols where the codebase is audited and your requirements are close to the original. Build from scratch only when existing protocols genuinely do not meet requirements — original protocols require original audits.

  • Build from scratch — maximum control, maximum audit cost, maximum time
  • Fork existing protocol (Uniswap, Compound) — battle-tested codebase, customisation
  • Integrate existing protocol — fastest, limits customisation, inherits protocol risk
  • White-label infrastructure — time to market, vendor dependency

• When to engage external audit?

  Impact: External audit before mainnet is the minimum. Architecture review before development and code review during development catches issues when they are cheapest to fix. External audit validates — it does not substitute for — internal security throughout development.

  • Before mainnet, always — minimum requirement
  • During development (continuous) — highest quality, highest cost
  • After development, pre-testnet — catches architecture issues before load
  • Post-launch (retroactive) — too late for findings that require redesign

What PROPELOO advises on.

• Blockchain Feasibility Assessment

  Structured assessment of whether a business problem justifies blockchain — requirements analysis, cost comparison and recommendation.

• Chain Selection Advisory

  Objective evaluation of blockchain platforms against specific technical and business requirements — not vendor preference.

• Tokenomics Review

  Independent economic model review — emission sustainability, value accrual, governance design and failure mode analysis.

• Smart Contract Architecture Review

  Pre-implementation review of smart contract system design — invariants, upgrade strategy, access control and attack surface.

• Technical Due Diligence

  Assessment of blockchain development teams, vendors or investee companies — code quality, architecture, security posture.

• DeFi Protocol Design

  End-to-end advisory for DeFi protocol design — mechanism design, economic modelling, security architecture and audit preparation.

Consulting toolchain.

• Analysis

  Stack: Tenderly (fork simulation), Dune Analytics, Etherscan/Solscan, DefiLlama, Token Terminal

• Architecture

  Stack: Miro (architecture diagrams), Excalidraw, draw.io, Notion (ADRs)

• Security Review

  Stack: Slither (static analysis), Echidna (fuzz), Foundry (PoC), Custom attack simulation

• Economic Modelling

  Stack: Python (token model simulation), Monte Carlo simulation, Excel/Google Sheets, Custom tokenomics models

• Chain Evaluation

  Stack: EVM chains (Ethereum, Arbitrum, Base, Polygon), Solana, Cosmos SDK, Hyperledger Fabric

• Deliverables

  Stack: Architecture decision documents, Tokenomics analysis reports, Security recommendations, Technical roadmaps

Security advisory is core to blockchain consulting.

• Economic attack modelling

  Flash loan attack surface mapping, oracle manipulation scenario analysis, governance capture feasibility and incentive misalignment identification — before a line of code is written.

• Architecture-level vulnerabilities

  Upgrade mechanism design review, multi-sig configuration recommendations, timelock requirements and emergency pause design — the decisions that cannot be changed after deployment.

• Third-party dependency risk

  Assessment of oracle providers, bridge dependencies, protocol integrations and infrastructure providers — mapping single points of failure and trust assumptions.

• Regulatory compliance risk

  Token classification analysis (utility vs security), jurisdiction-specific regulatory risk, KYC/AML requirements for on-chain operations and licensing recommendations.

• Audit firm selection

  Objective recommendations for third-party audit firms based on protocol type, chain, budget and timeline — not referral relationships.

• Incident response preparedness

  Emergency pause mechanism design, guardian multi-sig setup recommendations, incident response playbook and communication plan for security events.

The consulting engagement.

1. 01. Problem Definition

   Structured workshop to understand the business problem, constraints and success criteria.

2. 02. Current State Assessment

   Review of existing architecture, code, tokenomics or technical documentation.

3. 03. Analysis

   Technical analysis, economic modelling, security review or feasibility assessment per engagement scope.

4. 04. Recommendation Development

   Structured recommendations with rationale, alternatives considered and risk assessment.

5. 05. Report Delivery

   Written report with executive summary, technical findings and prioritised recommendations.

6. 06. Review Session

   Workshop to review findings, answer questions and refine recommendations based on feedback.

7. 07. Follow-on Support

   Optional follow-on engagement to support implementation of recommendations.

Frequently Asked Questions