01
Permissioned network deployment
Hyperledger Besu, Polygon Edge, or Ethereum-based permissioned chains. KYC-gated participation, validator-set governance, audit-grade tracing, and integration with existing identity infrastructure.
Loading…
Blockchain & Web3 · MESH
Enterprise Chain Integration.
Permissioned chain deployments, oracle bridges to public networks, audit-grade tracing, and compliance-aware on-chain integration for institutional and regulated clients. Engineered against the procurement reality, not the conference-stage demo.
- Practice
- Blockchain & Web3
- Department
- MESH
The problem
Most enterprise blockchain projects ship a Hyperledger fork that nobody uses and a slide deck that promised a transformation.
The pattern that produces it: a procurement-driven blockchain mandate uncoupled from a real use case; a permissioned-chain deployment that nobody integrates with the existing back-office; a 'consortium' that's two members and a steering committee; a public-chain integration scoped as 'phase 2' that never ships; and an audit-trail pattern that produces JSON nobody can validate against the data warehouse. Enterprise blockchain fails when it's solving for a procurement mandate rather than for a workload.
We engage on enterprise blockchain only where there's a real workload and the trust model genuinely benefits from on-chain settlement, immutable audit, or cryptographically-verifiable provenance. We design with explicit answers to 'why on-chain', integrate to existing back-offices through documented contracts, deploy with the regulatory frame in mind, and stand up the bridge architecture to public networks where secondary liquidity matters. We will tell you when 'put it on chain' is the wrong answer.
Where it ships
5 use cases, in production.
Specific applications we’ve built and operated. Not speculative — every example below is grounded in a real shipped engagement.
- 02
$120M
issuance year one
Tokenized assets with public-chain bridge
Asset issuance on a permissioned chain with audited bridge to Ethereum mainnet for secondary liquidity. ERC-3643-aligned compliance, jurisdictional access controls, and explicit liquidity-management strategy.
- 03
Supply-chain provenance
Cryptographic provenance tracking for high-value goods, with off-chain ERP integration, oracle bridges to public networks for verification, and audit reporting that survives regulator inquiry.
- 04
Cross-organization workflow
Multi-party workflows where on-chain consensus genuinely improves trust (trade finance, multi-bank reconciliation). We tell you when off-chain message-passing achieves the same outcome at lower complexity.
- 05
Audit-trail integration
On-chain audit trails for regulated workflows, integrated with existing audit and reporting systems through documented contracts. Privacy-preserving where the regulatory frame requires it.
How we engage
4 phases, named in the SOW.
Each phase has a deliverable, an owner, and an acceptance criterion. Not slogans — operating rules.
- 01
'Why on-chain' analysis
Discovery starts with that question. We model the workload, identify the trust assumptions, and assess whether on-chain settlement / audit / provenance genuinely improves the operational reality. Some engagements end with 'use a database with a Merkle tree' — and we say so.
- 02
Architecture against procurement reality
Permissioned vs public, EVM vs non-EVM, validator topology, identity model, audit-trail format, and the integration story to existing back-offices. Architecture lands in writing including explicit answers to procurement and InfoSec questions.
- 03
Engineering with regulatory frame
Compliance-aware contracts (ERC-3643, ERC-1404 patterns where applicable), KYC-gated participation, sanctioned-address screening, jurisdictional access controls, and the audit-trail tooling that integrates with existing reporting.
- 04
Operating discipline
Bridge monitoring, validator-set health, audit-trail reconciliation, and the runbook for incident response. Many engagements continue under Managed Services for ongoing operations and quarterly architectural review.
Capabilities
What’s in scope.
- Permissioned-network deployment: Besu, Polygon Edge, Quorum, Corda
- Public-chain integration with audited bridges and oracle aggregation
- Compliance-aware tokens (ERC-3643, ERC-1404) and KYC-gated transfers
- Audit-trail tooling with privacy-preserving patterns where required
- Identity integration: Microsoft Entra ID, Okta, Auth0, custom IdPs
- Back-office integration: ERP, treasury, audit, reporting systems
- Jurisdictional access controls and sanctioned-address screening
Stack
Tools we use in production.
- Permissioned chains
- Hyperledger BesuPolygon EdgeQuorumCordaHyperledger Fabric
- Public chains
- EthereumPolygonArbitrumBaseOptimism
- Bridges
- LayerZeroWormholeAxelarCustom institutional bridges
- Compliance
- ERC-3643 (T-REX)ERC-1404ChainalysisTRM Labs
- Identity & integration
- Microsoft Entra IDOktaOnfidoSumsubCustom adapters
Selected work
Quantified outcomes, not adjectives.
Common questions
Asked before the first call.
- 01
Do we even need a blockchain?
Most of the time, no. We tell you in discovery. Blockchain genuinely improves the operational reality when (1) settlement requires multi-party consensus without a trusted intermediary, (2) immutable audit trails serve a regulatory or legal frame, (3) cryptographic provenance is the use case (high-value goods, art, credentials), or (4) tokenization unlocks secondary liquidity. Most other use cases are better served by a database with a Merkle tree.
- 02
Permissioned or public chain?
Permissioned for use cases where participants are known, regulatory frame requires gated access, and confidential data flows on-chain. Public for use cases where secondary liquidity, censorship resistance, or open ecosystem participation matters. Many institutional setups use both — issuance on a permissioned chain with bridge to a public chain for liquidity.
- 03
Hyperledger Fabric or Besu?
Besu for use cases where EVM compatibility, public-chain interoperability, or smart-contract portability matters. Fabric for use cases where channel privacy, MSP-based identity, and the IBM / Oracle support ecosystem are critical. The architecture decision lands in writing during discovery — including explicit tradeoffs.
- 04
How do you handle compliance?
ERC-3643 (T-REX) is our default for compliant token issuance — KYC-gated transfers integrated with the issuer's compliance partner, jurisdictional access controls, sanctioned-address screening, and audit-trail tooling that reports to the regulator's expectations. We've shipped this for institutional issuers in financial services and real estate.
- 05
Can you integrate with our ERP / back-office?
Yes — and that's where most enterprise blockchain projects fail. We design back-office integration as primary scope, not phase 2. SAP, Oracle, Dynamics 365, and custom ERP integrations through documented APIs. Treasury, audit, reporting, and identity systems integrated through the same documented contracts.
- 06
What does an enterprise chain engagement cost?
Architecture and 'why on-chain' analysis: 4–8 weeks, $80K–$250K. Permissioned-chain deployment with back-office integration: 6–12 months, $800K–$2.5M. Tokenization platform with bridge: $1M–$3M. Multi-party consortium programs: $2M–$6M+. External audit fees pass through. Managed Services: $50K–$200K monthly retainer. Brackets published honestly so visitors self-qualify before the first call.
Within Blockchain & Web3
Other capabilities in this practice.
Talk to us
Bring a enterprise chain integration problem. We’ll bring a senior engineer.
A senior engineer plus the MESH department lead joins the first call. No discovery gauntlet, no junior reps.