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 what's still alpha.

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)

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:

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 hashes and signs with secp256k1. Keys never touch the API:

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

const sdk = new ClutchHubSdk('https://api-stage.clutchprotocol.io', publicKey);
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 — honest alpha limitation.

CLT economics (driver-first)

Ride payments and validator rewards are separate:

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 — API receives signed RLP hex, not private keys
• Wallet JWT — identity is a public key (generateToken), no passwords
• Nonce anti-replay — per-account nonce enforced on-chain
• Faucet — only server-side signer, testnet Transfer only; disable in production

Try it in 3 minutes (no install)

1. Open https://app-stage.clutchprotocol.io
2. Choose Passenger or Driver → generate wallet → Request CLT (faucet)
3. 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

npm install clutch-hub-sdk-js

What's alpha (honest limitations)

• Testnet only — no mainnet, small validator set on stage
• DAO governance — roadmap, not shipped
• ConfirmArrival / ComplainArrival — stubs in the node, not in Hub/SDK yet
• Hub subscriptions poll the node; not push-from-chain yet
• 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

1. Domain-specific chain vs. smart contracts — worth it for ride-sharing, or would you always pick an L2?
2. Referrer-fee model for app builders — sensible incentive or weird?
3. 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.