DEV Community: MADAR Network

Why every node operator in our network gets exactly one vote

MADAR Network — Tue, 20 Oct 2026 15:02:23 +0000

Most blockchains give power to whoever holds the most coins. Proof of stake is efficient, but it means the largest holders decide which blocks are final and which upgrades pass.

We wanted to try something different with MADAR Network: one person, one vote.

What that means

Every approved operator runs one node and gets exactly one vote in finality. Holding more coins does not give you more votes. There is no staking.

Why we chose it

Fairness you can explain in one sentence. Anyone can understand "one person, one vote".
No race to accumulate. Influence does not grow with wealth.
A network of people, not wallets. Each vote stands for someone who chose to run a node.

The hard part

One person, one vote only works if one person cannot pretend to be many. Today, a committee approves operators, which keeps the rule but does not scale. We are looking for better answers, and we would like to hear yours.

Where it stands

MADAR runs as a public testnet. There is no token yet. The code is open source (Apache-2.0) on GitHub: https://github.com/MADAR-NETWORK/MADAR

Run a node

You do not need technical skills: install the app on Windows or Linux, keep your computer on, and after approval one button turns on voting. Early operators get a founder number on the public leaderboard.

https://madar-network.com/operators/

This article was written with the help of AI.

Why we built a blockchain with one vote per person

MADAR Network — Sun, 18 Oct 2026 15:37:04 +0000

Most blockchains say they are decentralized, but voting power usually follows money: more hardware or more coins means a bigger voice. We wanted to try the opposite, so we built MADAR Network: an independent layer-1 chain where every approved operator has exactly one vote.

The idea

One vote per person. An operator's weight does not grow with balance or hardware.
No master key. There is no sudo; every change to the rules needs two of three committee approvals.
It survives without us. Nodes find each other on their own; our website and servers are outside consensus.
Safety before liveness. If a safe decision cannot be made, the network pauses rather than accept a wrong history.

Why not invent new consensus?

We deliberately used proven parts: Polkadot SDK, BABE for block production and GRANDPA for finality, with no changes to the consensus algorithms. Our own work sits in a separate admission layer.

The hard part: one person, one vote

The real challenge is stopping one person from posing as many. Our answer at this stage is honest and slow:

The committee approves each new operator after talking to them directly, at most one new operator per day.
We never ask for ID documents or photos.
The approved account solves a memory-hard puzzle (pass or fail, so a faster machine gains nothing), and a fair draw picks who joins each round.

It is not perfect, and the whitepaper says where it is weak. But it keeps growth deliberate while the network learns.

Running a node should be simple

Operators install a desktop app, register, and after approval one button turns on voting. The app creates the voting keys on the operator's own computer and renews membership on time.

Where we are

MADAR is a public testnet today. The currency, MDR, only starts with the mainnet. We are now looking for the first ten independent operators in different places.

Whitepaper (English / Arabic): https://madar-network.com/whitepaper/
Source code (Apache-2.0): https://github.com/MADAR-NETWORK/MADAR
Become an operator: https://madar-network.com/operators/

Questions and criticism are welcome in the comments.

This article was written with the help of an AI assistant and reviewed by the MADAR team.

What we learned from our first cross-network transfer

MADAR Network — Sun, 11 Oct 2026 11:51:41 +0000

A short case study from MADAR Network — October 2026

Moving money from one blockchain network to another is still one of the most confusing things a regular user can do. When we added cross-network transfers to Madar Swap, our swap page, we set ourselves two rules before writing a single line:

Nobody should sign something they cannot read.
Nobody should need a block explorer to know where their money is.

This post describes why we chose those rules, what they look like for a user, and the numbers from our first real transfer.

The problem

A typical cross-network transfer looks simple on the surface: pick a network, pick a token, press a button. Underneath, the wallet asks the user to approve a contract they have never heard of, then to sign a transaction whose content is a long string of hexadecimal characters. After that, the money "leaves" one network and, some minutes later, "appears" on another.

Between those two moments, most users are on their own. If they want to know what is happening, they are sent to block explorers, transaction hashes and bridge dashboards that were built for developers, not for people sending their savings.

We think this is where most of the fear around bridges comes from: not the technology itself, but the feeling of losing sight of your money.

Rule 1: no signature without a check

Before the wallet ever opens, the page checks the transaction it is about to ask the user to sign against what the user actually asked for: where the money goes, how much, which tokens, which networks, and who receives it on the other side. If anything does not match, the page refuses to continue and says so plainly. The user is never asked to sign a transaction that differs from the screen they agreed to.

Before agreeing, the user also sees every number that matters, in one place:

the minimum amount they will receive,
the total fees, as one percentage,
the network fee.

Rule 2: a tracker instead of an explorer

After sending, the page shows a tracker with four plain stages:

Sent from your wallet
Network confirmations
On its way
Arrived in your wallet

Each stage is driven by the real status of the transfer, not by a timer. We removed the "estimated time" line entirely: an estimate that is wrong does more harm than no estimate, and a tracker that moves only when something actually happens is more honest. If the user closes the page, the tracker comes back when they return. If a transfer cannot complete, the tracker says the amount is being returned, instead of leaving the user guessing.

The first real transfer

On October 11, 2026 we ran the first real transfer through the service:

Step	Result
Paid	1.35 USDC on Base
Shown before signing	1.338525 USDC on Ethereum
Received	1.338525 USDC on Ethereum
Time	about 27 minutes

The amount received matched the amount shown before signing, to the last digit.

The time was the most useful lesson. The route chosen for this pair waits for the source network to settle before releasing funds on the other side, so it took longer than a fast route would. That is exactly the situation where a user without a clear tracker starts to worry, and exactly why we built one.

What we took away

Clarity is a feature. The same transfer feels very different when the user can see each stage.
Honest numbers beat optimistic ones. Showing the minimum received, rather than the best case, sets the right expectation.
Remove what you cannot promise. We dropped the time estimate because we could not guarantee it.

Madar Swap is part of MADAR Network. Funds always stay in the user's own wallet; the page never holds money or keys.

madar-network.com