DEV Community: Mehran Mazhar

Making MetaMask and TronLink sign transactions for a custom Rust blockchain

Mehran Mazhar — Thu, 29 Oct 2026 16:41:21 +0000

A few months ago I wrote How I Built a Custom Rust Blockchain for On-Chain Ride Lifecycle. Clutch is a ride-sharing protocol where the rider pays the driver directly, and every step of a ride (request, offer, accept, pay, cancel) is a native transaction type on a small Proof-of-Authority chain written in Rust.

Since then it went from "testnet with a faucet" to a mainnet that holds real money. This post is about the parts I did not expect to be hard: getting normal wallets to sign for a chain they have never heard of, and keeping the token honest once it is backed by real USDT.

If you read part 1: block rewards are gone. The block author is now paid by a flat fee on each transaction.

The problem: wallets refuse to sign a bare hash

In part 1, the SDK held a local key and signed the transaction hash directly:

hash = keccak256(rlp([from, nonce, chain_id, data]))
signature = secp256k1_sign(keccak256(hash_as_hex_string))

That works for an SDK. It does not work for MetaMask or TronLink. A wallet will not sign 32 opaque bytes for you, and it is right not to: a bare hash could be an Ethereum transaction on another chain.

So the node now accepts three schemes, each checked against its own digest:

Scheme	Who signs	What is signed
1	SDK key, treasury, faucet	`keccak256(hash)`
2	MetaMask, Trust Wallet (`personal_sign`, EIP-191)	`"\x19Ethereum Signed Message:\n" + len + "clutch-tx:{chain_id}:{hash}"`
3	TronLink (`signMessageV2`, TIP-191)	`"\x19TRON Signed Message:\n" + len + "clutch-tx:{chain_id}:{hash}"`

The text the user sees in the wallet popup is clutch-tx:{chain_id}:{hash}. The chain id is in it so a signature for the testnet can never be replayed on the mainnet.

The nice surprise was TRON. A TRON account is the same kind of key as an Ethereum account: same curve, same Keccak-256, same 20 address bytes. TRON just writes them in base58 with a 0x41 prefix. So supporting TronLink was one more prefix, not a new crypto stack. A user signed in with TronLink has a Clutch address that is literally their TRON address in hex.

The catch: this is a consensus change. A validator without scheme 2 rejects any block containing a scheme-2 transaction. On a testnet you just upgrade. On our young mainnet it meant starting a new chain, which we only allowed because a script first proved that no token had ever been minted on the old one. The day real balances exist, the same change needs a planned rolling upgrade of every validator from the same block height.

Sending from MetaMask: pretending to be just enough of an EVM

Signing ride transactions in the app was solved. But people also wanted to open MetaMask, see their CLT balance, and press Send.

MetaMask can only send by signing a legacy Ethereum transaction (EIP-155). So the Hub API exposes a small JSON-RPC endpoint at /rpc that answers the calls a wallet makes (eth_chainId, eth_getBalance, eth_sendRawTransaction and friends), and the node gained one new transaction type, WalletTransfer:

The node decodes the raw Ethereum transaction and recovers from from its signature.
It refuses anything that is not a plain value transfer: data, typed transactions, no chain id, a high s.
Wallet values are in wei (18 decimals); CLT has 6. So value = CLT units × 10^12, and any value with more than 6 decimals is refused, never rounded. Rounding money silently is how you end up with balances nobody can explain.
The transaction's hash is the real Ethereum hash, rebuilt from the fields and signature, so MetaMask, the explorer and the node all show the same hash.

This is also a consensus change, so it is switched on per chain by config: a wallet_chain_id and a wallet_transfers_from_block height that every validator must carry. Below that height the type is refused everywhere. The wallet chain ids (20770 mainnet, 20771 testnet) are registered on chainlist, so "Add network" works with one click.

Real money: CLT backed 1:1 by USDT

1 USD = 1,000,000 CLT base units. CLT only enters the chain through a Mint transaction, and only one address can sign it: the mint_authority, fixed in the genesis block. A separate treasury service watches for USDT deposits (TRC-20 on Tron, BEP-20 on BNB Chain), and mints the matching CLT to the depositor (minus the transfer relay's fee, for deposits that go through one). Withdrawals are the reverse: a Burn on Clutch, then a USDT payout on Tron.

Every mint and burn carries a reference, and the chain stores a processed_ref_{ref} marker so the same deposit can never be credited twice, even if the treasury retries after a crash.

Three bugs that could have created money

These are the ones that scared me. All are fixed, all have tests, and I am writing them down because each one looked harmless.

1. Two transfers in one block minted money. Block state is validated first and applied as one deferred RocksDB batch at the end. So two transfers from the same account in one block were both validated against the pre-block balance, and the second write to the balance key won. Send 10 to A and 10 to B from a balance of 10: both pass, both recipients get 10, the sender ends at 0. Fix: one transaction per account per block, enforced when authoring and when importing. The same staleness broke the exactly-once marker (two mints with one ref in one block), so a block also may not repeat a ref.

2. The block author's fee erased the author's own transaction. The fee credit to the block author was appended after the per-transaction writes, so it became the last write to the author's balance key and silently discarded any transaction the author had sent in that block. The recipient kept the money, the author's debit vanished: unbacked CLT. Fix: fold the fee into the already-staged write instead of appending, and abort the import if that fails.

3. A debug flag deleted the chain on every deploy. developer_mode = true made the node delete its database on graceful shutdown. Our stage configs had it for a month. Whichever node stopped cleanly inside Docker's 30-second grace period lost its chain; the ones that got SIGKILLed kept theirs. So the data loss moved between nodes and looked like a volume problem, then a sync problem, then a deploy-script problem. The node now refuses to delete its database when a data path is mounted.

The lesson I took from all three: with a deferred write batch, "last write wins" is a money bug waiting for a second writer.

Where it is now, honestly

The mainnet has been live since October 2026 and holds real USDT.
It is alpha: $100 per deposit, $200 per day, withdrawals of $25 to $50 on Tron.
The mint and payout keys are on the server, not in a KMS yet. The three validators run on one host. There has been no security audit.

Because of that, I am asking people to try the free testnet first, where nothing costs real money: app-stage.clutchprotocol.io. Sign in with MetaMask or TronLink, and do one ride as passenger or driver (two browser windows work).

I am looking for 10 people to finish one ride and tell me the first thing that confused them or broke. Comments here are perfect.

How I Built a Custom Rust Blockchain for On-Chain Ride Lifecycle

Mehran Mazhar — Fri, 26 Jun 2026 15:08:49 +0000

Update: part 2 covers wallets, real USDT backing and three money bugs.

Mehran Mazhar

Oct 29

Making MetaMask and TronLink sign transactions for a custom Rust blockchain

#rust #blockchain #web3 #opensource

6 min read

I wanted ride-sharing operations — request, offer, accept, pay, cancel — to be first-class on-chain transactions, not generic smart-contract calls wrapped in app logic. So I built Clutch Protocol: a custom non-EVM blockchain in Rust, a GraphQL bridge for apps, a JavaScript SDK for client-side signing, and a public stage testnet you can try without installing anything.

This post is the technical story: what I built, why I didn't use Ethereum, how a ride actually flows through the stack, and — just as importantly — what I haven't solved yet.

The problem I was solving

Traditional ride apps centralize trust: the platform owns matching, payments, and dispute resolution. Putting the ride state machine on-chain changes the contract between riders, drivers, and app builders:

Every step is a signed, auditable transaction
Private keys stay on the client (Bitcoin-style)
App developers can earn on-chain referrer fees when users complete rides
Drivers receive CLT directly via RidePay, not through a platform ledger

The tradeoff is real: you lose EVM composability and must ship custom SDKs. For a domain-specific protocol, that tradeoff felt acceptable.

Architecture at a glance

Demo App / Your dApp
        │
        ▼
  clutch-hub-sdk-js   (client-side signing, RLP, secp256k1)
        │
        ▼
  clutch-hub-api      (GraphQL + WebSocket + faucet)
        │
        ▼
  clutch-node         (Aura consensus, WebSocket JSON-RPC)
        │
        ▼
  clutch-explorer     (indexer → Postgres → REST UI)

Component	Role	Stack
clutch-node	Blockchain core	Rust, Aura, libp2p
clutch-hub-api	App bridge	Rust, async-graphql
clutch-hub-sdk-js	Client SDK	TypeScript, npm
clutch-hub-demo-app	Reference UI	React, Vite, Leaflet
clutch-deploy	Full stack	Docker Compose

Docs: https://docs.clutchprotocol.io

Why a custom chain (and not Ethereum)

Clutch is non-EVM. Ride operations are native transaction types with RLP encoding:

Tag	Type	Purpose
1	`RideRequest`	Passenger requests a ride
2	`RideOffer`	Driver offers to fulfill
3	`RideAcceptance`	Passenger accepts; fare debited
4	`RidePay`	Payment installment to driver + referrers
5	`RideCancel`	Cancel trip; refund unpaid fare
8	`RideRequestCancel`	Cancel pending request

(Tags 6–7 are intentionally unused — they held two arrival-confirmation types I removed while simplifying the state machine.)

Apps don't deploy contracts. They call the Hub API for unsigned payloads, sign locally, and submit signed RLP hex. The node validates signatures, nonces, and applies the ride state machine.

What you gain: simpler app surface, predictable tx format, ride logic enforced in the node.

What you lose: DeFi composability, existing wallet/tooling, large validator ecosystem.

How a ride works (end to end)

RideRequest → RideOffer(s) → RideAcceptance → RidePay → completed
     ↓                              ↓
RideRequestCancel              RideCancel

1. Build unsigned transaction (server)

The Hub API constructs the payload and injects referrer addresses from config:

mutation {
  createUnsignedRideRequest(
    pickupLatitude: 35.7,
    pickupLongitude: 51.4,
    dropoffLatitude: 35.8,
    dropoffLongitude: 51.5,
    fare: 1000
  )
}

Returns JSON like:

{
  "from": "0x...",
  "nonce": 3,
  "data": {
    "function_call_type": "RideRequest",
    "arguments": { }
  }
}

2. Sign client-side (never send private keys)

The SDK holds your key locally and signs with secp256k1 — the key never touches the API. It's also what signs the auth challenge, so pass it when you construct the SDK:

import { ClutchHubSdk } from 'clutch-hub-sdk-js';

// privateKey stays in the client; it signs both the auth challenge and txs.
const sdk = new ClutchHubSdk('https://api-stage.clutchprotocol.io', publicKey, privateKey);

// ensureAuth signs a timestamped challenge with your key to get a short-lived JWT.
await sdk.ensureAuth();

const unsigned = await sdk.createUnsignedRideRequest({
  pickup: { latitude: 35.7, longitude: 51.4 },
  dropoff: { latitude: 35.8, longitude: 51.5 },
  fare: 1000,
});

const signed = await sdk.signTransaction(unsigned, privateKey);

3. Submit signed transaction

await sdk.submitTransaction(signed.rawTransaction);

The Hub forwards to the node over WebSocket JSON-RPC (send_raw_transaction). Validators include the tx in a block; state updates atomically.

4. Read state (GraphQL or subscriptions)

const requests = await sdk.listRideRequests();
await sdk.subscribeRideRequests((updated) => {
  console.log('Open requests:', updated.length);
});

Subscriptions multiplex over a shared WebSocket to /graphql/ws. Under the hood the API polls the node (~0.5–1s) and pushes snapshots — an honest alpha limitation.

CLT economics (driver-first)

Ride payments and validator rewards are separate:

Layer	Mechanism	Default
`RidePay`	Referrer fees + driver remainder	2% request + 2% offer
Blocks	Fixed reward to block author	50 CLT per block

Example: 10 CLT fare, one full RidePay, both referrers set:

Request referrer: 1 CLT
Offer referrer: 1 CLT
Driver: 8 CLT

App builders: run your own Hub API, set your wallet as default_ride_request_referrer / default_ride_offer_referrer, and earn CLT when users complete rides on your deployment. No separate grants program — rewards come from real ride activity.

Details: https://docs.clutchprotocol.io/getting-started/app-developer-incentives

Security model

Client-side signing only — the API receives signed RLP hex, never private keys
Wallet auth via a signed challenge — you prove key ownership by signing a timestamped message (no passwords), which mints a short-lived JWT
Nonce anti-replay — per-account nonce enforced on-chain
Faucet — server-side signer only, testnet Transfer only; disabled in production

Try it in 3 minutes (no install)

Open https://app-stage.clutchprotocol.io
Choose Passenger or Driver → generate wallet → Request CLT (faucet)
Passenger: request a ride on the map · Driver: submit an offer

Full tutorial: https://docs.clutchprotocol.io/getting-started/ride-lifecycle

Run the full stack locally

git clone https://github.com/clutchprotocol/clutch-deploy.git
cd clutch-deploy
cp .env.example .env
docker compose up -d

Service	URL
Demo app	http://localhost:5173
Hub API	http://localhost:3000/health
Explorer	http://localhost:5174

npm install clutch-hub-sdk-js

What's Alpha

This is an honest work-in-progress, not a finished product:

Testnet only — CLT is free test currency; nothing real is charged.
No reputation or ratings — nothing scores drivers or riders yet.
No dispute resolution — cancellations are on-chain, but there's no arbitration when two parties disagree, and no no-show/fraud handling.
Matching is naive — no surge pricing or geospatial optimization.
Subscriptions poll the node (~1s) rather than true push.
DAO governance is on the roadmap, not in the code.
APIs may change without notice.

Open source

Eight public repos under https://github.com/clutchprotocol

Star the org if this is interesting
Discussions: https://github.com/orgs/clutchprotocol/discussions
Issues and PRs welcome — conventional commits appreciated

Questions I'd love feedback on

Dispute resolution & reputation — this is the part I haven't built and find hardest. With no central operator to force a refund, what actually works: escrow with a timeout, staked third-party arbitrators, something else? If you've shipped marketplace or payments infra, I'd genuinely value your take.
Domain-specific chain vs. smart contracts — worth it for ride-sharing, or would you always reach for an L2?
Referrer-fee model for app builders — sensible incentive, or weird?
What would you build on this stack?

Links

Website: https://clutchprotocol.io
Docs: https://docs.clutchprotocol.io
Stage demo: https://app-stage.clutchprotocol.io
npm SDK: https://www.npmjs.com/package/clutch-hub-sdk-js
GitHub: https://github.com/clutchprotocol

Built by Mehran Mazhar (GitHub). Alpha software — use at your own risk.