# Enterprise & Private Blockchain Enterprise and private blockchain development: permissioned networks built on the audited contract engineering we ship to public chains. India and global. Canonical: https://www.metaborong.com/services/web3/enterprise-private-blockchain Service: web3/enterprise-private-blockchain ## Overview Enterprises rarely fail at blockchain because the idea is wrong; they fail because a permissioned network is run as a pilot, with no threat model, no audited contracts, and no membership governance. Enterprise blockchain development is the engineering practice that builds permissioned and consortium networks where access, validators, and on-chain logic are controlled by named parties. We bring the same audit-grade contract engineering we ship on public chains to private and consortium deployments. ## What is it? Enterprise blockchain development is an engineering practice for enterprises and consortia that builds permissioned and private networks where access, validators, and on-chain logic are controlled by named parties. It brings audit-grade contract engineering to gated deployments. Our public-chain contracts cleared four Hacken audit rounds. We ship across EVM, Solana, Cosmos, and Aptos. ## What we deliver - Permissioned network topology with defined validator set and membership rules. - Audit-grade contracts with threat model, invariant tests, and NatSpec. - Role-based on-chain permissions tied to your consortium governance. - Monitoring for validator health, role changes, and privileged calls. - Operator runbook covering node onboarding, upgrades, and incident response. ## Key concepts **Permissioned blockchain**: A permissioned blockchain is a network where participation, validation, and read access are restricted to identified, vetted members rather than open to anyone. Membership is governed by an explicit policy, often a consortium agreement, which makes the network suitable for enterprises that need a shared ledger without exposing data or block production to the public. **Consortium validator set**: A consortium validator set is the defined group of organisations permitted to produce and validate blocks on a shared network. Unlike public chains, where validators are anonymous and economically incentivised, consortium validators are named parties whose admission, removal, and voting weight are fixed by governance, distributing trust across members rather than a single operator. **Role-based on-chain permissions**: Role-based on-chain permissions encode who may call which contract function as access-control logic on the chain itself, rather than as a trusted off-chain check. Roles such as admin, minter, or auditor are granted to specific addresses and changes are recorded on-ledger, so every privileged action is attributable and verifiable by any member. **Threat model**: A threat model is a written enumeration of how a system can be attacked: access-control failure, key compromise, economic exploit, and consensus-level collusion in a consortium. It is drafted alongside the specification, before code, so each design decision is made against a named adversary rather than discovered during an external audit. ## How we work 1. **Network & trust design** We map who participates, who validates, and who can read what, before choosing a platform. The output is a permissioned topology: validator set, membership admission rules, data-visibility boundaries, and the off-chain governance that controls them. We name the trust assumptions explicitly, because in a consortium the hard problem is rarely the chain, it is who holds which key and how a member is added or removed. 2. **Contract & permission engineering** On-chain logic is built against a written specification with property-based invariant tests and the same threat model discipline we apply on public chains. Role-based permissions are encoded as contract-level access control rather than trusted off-chain checks. A second engineer runs an internal audit pass line by line against the threat model before any external review, filing what they could not break. 3. **Network deployment** We stand up the validator nodes, configure the consensus and membership policy, and deploy verified contract sources. Privileged roles transfer to the multisigs or HSMs the consortium agreed on, never a single operator. Every node onboarding, permission grant, and parameter change is documented so a member organisation can audit the network state without depending on us. 4. **Operate & hand-off** After go-live we monitor validator health, role changes, and large or privileged transactions, and respond to incidents on a defined SLA. Parameter changes ship through the agreed governance process, not ad-hoc admin keys. We write operator documentation so an in-house or consortium team can run nodes, admit members, and execute upgrades cleanly once the engagement ends. ## Tech stack Hyperledger Besu (Permissioned EVM), Hyperledger Fabric (Consortium), Polygon Supernets (App-chain), Polygon Edge (App-chain), Solidity (Contracts), Foundry (Testing), OpenZeppelin (Access Control), Slither (Static Analysis), Tenderly (Monitoring) ## When this fits ### Fits when - Multiple organisations need a shared ledger where membership and validators are explicitly controlled. - You need on-chain logic engineered for audit, not a proof-of-concept that never reaches production. - A named team can own consortium governance: who validates, who joins, who holds keys. ### Does not fit when - A single internal team would be better served by a conventional database with an audit log. - You want a permissionless public token launch rather than a controlled, gated network. - There is no appetite for the audit and key-custody discipline a permissioned chain requires. ## FAQ ### What is the difference between a private and a permissioned blockchain? A private blockchain is operated by a single organisation that controls all nodes. A permissioned, or consortium, blockchain distributes validation across several named organisations under a shared governance policy. Both restrict who can participate, but a consortium network spreads trust so no single member can rewrite history alone. We design for whichever trust model the use case actually needs, and we name those assumptions before choosing a platform. ### Have you built enterprise consortium networks before? Our shipped record is on public and app-specific chains: audited DeFi and token contracts across EVM, Solana, Cosmos, and Aptos. Permissioned deployment is the same engineering discipline applied to a gated network, with validator and membership control added. We bring the audit-grade contract work and threat modelling that production demands, and platform expertise in Hyperledger Besu, Fabric, and Polygon Supernets, rather than a first-time pilot mindset. ### Which permissioned platform should we use? It follows the trust and tooling requirements, not preference. Hyperledger Besu suits teams that want EVM compatibility and existing Solidity tooling on a private network. Fabric fits when channels and fine-grained data isolation between members matter more than EVM portability. Polygon Supernets or Edge make sense when you want an app-specific chain that can later bridge to a public network. We document the decision so each consortium member sees the rationale. ### How do you keep contracts on a private chain secure? The chain being private does not lower the bar. We apply the same practice that cleared four Hacken rounds for Neemo Finance: a written specification, a threat model, property-based invariant tests, and an internal audit pass before external review. Role-based permissions are enforced on-chain, privileged keys live in multisigs or HSMs, and we monitor validator health and privileged calls after go-live on a defined SLA. ### Can a permissioned network connect to a public chain later? Yes, and we design for it when it is a stated goal. An app-specific or consortium chain can settle proofs or bridge assets to a public network once the membership and contract layers are stable. We treat the bridge as a separate, audited surface with its own threat model, because cross-chain messaging is a common exploit class. We do not bolt a bridge on without that review.