--- title: Blockchain protocol development url: "https://www.unknowngravity.com/en/servicios/desarrollo-de-protocolos-blockchain" site: Unknown Gravity published: "2025-01-28T13:44:56+00:00" modified: "2026-07-15T10:51:34+00:00" language: en-US description: We design and implement advanced solutions that allow you to create decentralized, efficient and fully customized ecosystems. section: "Home > Blockchain protocol development" --- # Blockchain protocol development > Blockchain protocol development means designing a network's base layer: consensus mechanism, block structure, incentive model and validation rules. It is different from building applications on top of an existing network. Unknown Gravity designs and implements custom protocols and layer-two networks. TAILOR-MADE DESIGN EFFICIENCY, SCALABILITY, AND INTEROPERABILITY COMPLIANCE AND REGULATION [Book a meeting](/en/meeting) Blockchain protocol development means designing a network's base layer: consensus mechanism, block structure, incentive model and validation rules. It is different from building applications on top of an existing network. Unknown Gravity designs and implements custom protocols and layer-two networks. **We design blockchain protocols from the consensus layer up: technical specification, test network and the documentation your team needs to run the nodes.** Before a line of code is written we tell you whether you actually need a network of your own. Most projects do not. ## 01 / What a blockchain protocol is, and when you need your own **A blockchain protocol is the set of rules that decides who may write to the network, how transactions are ordered, what counts as a valid block and how nodes settle disagreements.** Building your own makes sense in a handful of specific situations: the execution model does not fit an existing virtual machine; confidentiality between participants means no third party can see the transactions; the latency or per-operation cost of public networks breaks the use case; or a consortium needs validation power split among its members under rules agreed in advance. ## 02 / When you do NOT need a protocol of your own **For most projects that reach our desk, the right answer is to deploy on an L1 or L2 that already exists.** A mature public network gives you validators you do not pay for, proven tooling, auditors who know the environment, custodians and exchanges already integrated, and users who install nothing new. A chain of your own starts with none of that. Clear signs you do not need one: your logic fits in smart contracts, your tokens have to circulate on existing markets, your team will not run infrastructure around the clock, or the expected volume does not justify a dedicated network. If control or privacy was the real concern, a [permissioned network](/en/servicios/blockchain-privadas) or a deployment on [Ethereum and EVM chains](/en/servicios/desarrollo-para-ethereum-evm) usually solves it. ## 03 / Consensus, nodes and governance: the three decisions that shape everything **Consensus:** who validates, and with what incentive. Proof of Stake, Proof of Authority and permissioned BFT are not interchangeable: they change the minimum validator set, fault tolerance, finality and what happens when an operator goes offline or acts in bad faith. **Nodes:** how many, who runs them and in which jurisdictions. Four nodes at the same cloud provider are not a decentralized network; they are a single point of failure with extra steps. **Governance:** how parameter changes and protocol upgrades get approved, and what happens when operators disagree. Settling this before launch prevents improvised forks. When the model includes on-chain voting, we cover it under [governance and voting](/en/servicios/blockchain-para-votaciones-y-gobernanza). ## 04 / The real cost of running your own network **Your own network does not end on launch day: that is where it starts.** You have to keep validators and archive nodes alive, run monitoring and alerting, coordinate upgrades across operators, answer incidents outside office hours, provide an explorer and RPC endpoints so anyone can actually use the chain, and maintain living documentation for operators who join later. That is people and recurring invoices, not a one-off payment. If the protocol issues a native token, its legal classification shapes the design: MiCA covers crypto-assets and utility tokens, while a token that qualifies as a financial instrument falls outside MiCA and under securities rules (LMVSI in Spain, MiFID II), with the **ERIR** (the entity responsible for registering and recording securities represented by distributed ledger technology, Arts. 7 and 8 of Law 6/2023) figure handling the register. Use the [MiCA/MiFID classifier](/en/clasificador-mica-mifid) to get your bearings; the legal opinion is your counsel's to sign. ## 05 / What you get: specification, testnet and node documentation **We work in phases, and each one closes with something you can review.** - **Technical specification:** consensus model, block and transaction format, network parameters, fee policy, permissioning and finality criteria. - **Working testnet:** a test network with several validators, faucet, explorer and sample data so your team can build against something real. - **Node documentation:** hardware requirements, installation, genesis bootstrap, syncing, key custody and rotation, and the upgrade procedure. - **Operations plan:** metrics to watch, alert thresholds and an incident runbook. We are a consultancy based in Málaga, Spain: 75+ projects delivered, 30+ clients and 0 hacks in production. If your case is better served without a network of your own, you will hear it in the first meeting. FAQ ## Frequently asked questions **When is a protocol of your own worth it compared with an existing L2?** It is worth it when you need validation or privacy rules a public network cannot give you, when a consortium has to split validation power among its members, or when latency and volume justify dedicated infrastructure. If your logic fits in smart contracts and you want liquidity from day one, an existing L2 ships sooner and costs less. **Which consensus mechanisms do you work with?** Proof of Stake, Proof of Authority and permissioned BFT variants, plus deployments on existing stacks in the EVM ecosystem. The choice depends on how many operators there are, how much they trust each other, and whether finality has to be immediate or probabilistic. **Can a protocol be upgraded after launch?** Yes, and it is planned from the design stage: versioning, coordinated upgrade windows across operators and backward compatibility to avoid unwanted forks. The later upgrade governance is defined, the more expensive every change becomes. This page is informative. It is not legal, tax or investment advice, and it does not replace a case-by-case review. The rules cited change: check the current version on [BOE](https://www.boe.es) and [EUR-Lex](https://eur-lex.europa.eu). RELATED SERVICES [Blockchain consulting for companies](/en/servicios/consultoria-blockchain) [Development of smart contracts](/en/servicios/company-development-smart-contracts) [Crypto Payment Gateway](/en/servicios/pasarela-de-pagos-crypto) [Smart contract auditing](/en/servicios/blockchain-security-audits) [Token issuance](/en/servicios/emision-de-tokens) [All blockchain services](/en/servicios)