Web3 · Engineering
Enterprise & Private Blockchain
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.
- 4Hacken audit rounds clearedNeemo Finance contracts
- 4chains shipped in productionEVM, Solana, Cosmos, Aptos
- Moveon Aptos, in productionKGEN token contracts
In short
What is Enterprise & Private Blockchain?
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
Concrete artefacts, not capabilities
- 01
Permissioned network topology with defined validator set and membership rules.
- 02
Audit-grade contracts with threat model, invariant tests, and NatSpec.
- 03
Role-based on-chain permissions tied to your consortium governance.
- 04
Monitoring for validator health, role changes, and privileged calls.
- 05
Operator runbook covering node onboarding, upgrades, and incident response.
Key concepts
Key terms, defined
- 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
Engagement phases
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.
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.
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.
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
What we build on
- Hyperledger BesuPermissioned EVM
- Hyperledger FabricConsortium
- Polygon SupernetsApp-chain
- Polygon EdgeApp-chain
- SolidityContracts
- FoundryTesting
- OpenZeppelinAccess Control
- SlitherStatic Analysis
- TenderlyMonitoring
- Hyperledger BesuPermissioned EVM
- Hyperledger FabricConsortium
- Polygon SupernetsApp-chain
- Polygon EdgeApp-chain
- SolidityContracts
- FoundryTesting
- OpenZeppelinAccess Control
- SlitherStatic Analysis
- TenderlyMonitoring
Scope
When this fits and when it doesn't
| This fits when | This doesn't fit when |
|---|---|
| Multiple organisations need a shared ledger where membership and validators are explicitly controlled. | A single internal team would be better served by a conventional database with an audit log. |
| You need on-chain logic engineered for audit, not a proof-of-concept that never reaches production. | You want a permissionless public token launch rather than a controlled, gated network. |
| A named team can own consortium governance: who validates, who joins, who holds keys. | There is no appetite for the audit and key-custody discipline a permissioned chain requires. |
Related services
Adjacent engagements
- Web3
Smart Contract Development
Solidity, Vyper, and Move contracts engineered for third-party audit, with tests and monitoring.
- Web3
Decentralized Identity & ZKP
Verifiable credentials, DID resolvers, and zero-knowledge selective disclosure. Live Aadhaar eKYC integration, portable across identity systems.
- Product Studio
SaaS Development
End-to-end SaaS builds with multi-tenancy, billing, and observability baked in.
Frequently asked questions
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.
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.
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.
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.
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.
Last reviewed · Reviewed by Metaborong engineering team
Tell us what you are building.
We build what large agencies under-deliver and freelancers can't architect, across Web3 protocols, AI agents, and SaaS products. Tell us what you are building. We will tell you how we would approach it, no pitch deck, no fluff, no commitment required.