Skip to main content

Transaction Types

Clutch Node supports custom non-EVM transaction types encoded with RLP tags.

Function call tags​

TagTypeHub API / SDKDescription
0TransferFaucet onlyStandard CLT transfer
1RideRequestYesPassenger requests a ride
2RideOfferYesDriver offers to fulfill a request
3RideAcceptanceYesPassenger accepts an offer
4RidePayYesPassenger pays driver (partial OK)
5RideCancelYesCancel active trip, refund unpaid fare
6MintNo — node onlyCredit CLT; only mint_authority may sign one
7BurnYes (createUnsignedBurn)Destroy CLT from the caller's own balance
8RideRequestCancelYesCancel pending request
9ChainInitNo — genesis onlyCarries consensus parameters into state at block 0

Tags are not contiguous by design: 6 and 7 were reserved ahead of time for Mint/Burn, and 9 was left open for ChainInit, added later still. Apps interact with types 1–5, 7, and 8 via the Hub API and SDK. Type 0 is used internally by the faucet. Types 6 and 9 never appear in application code — see below.

Ride lifecycle​

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

Mint (tag 6)​

Credits CLT to an address. This is the chain's only on-ramp for new supply.

Mint { to: address, amount: u64, credit_ref: 64-hex-chars }
  • Only the address recorded as mint_authority in genesis may sign a Mint — any other sender is rejected before it reaches the pool.
  • credit_ref is the hash of an off-chain deposit intent (e.g. a specific bank transfer or card charge). The node records every credit_ref it has processed and rejects a repeat — so a retried or duplicated deposit request can never credit twice, no matter how many times the caller retries it.
  • Mint is fee-exempt: the mint authority is not required to hold CLT of its own in order to credit users.

Not exposed via the Hub API or SDK — it is constructed and signed directly against the node by whoever holds the mint authority key. See CLT Economics for why this operation exists and what guarantees the chain does (and does not) provide around it.

Burn (tag 7)​

Destroys CLT from the caller's own balance. This is the chain's only other supply-changing operation, and the counterpart to Mint.

Burn { amount: u64, redemption_ref: optional 64-hex-chars }
  • Permissionless — any account may burn its own balance; there is no authority check.
  • redemption_ref is optional. When present, it's the hash of an off-chain redemption intent, letting an off-chain payout worker match a confirmed burn to the withdrawal it should trigger. A plain burn (no off-chain counterpart) omits it.
  • Burn pays the flat tx_fee like most other transaction types — the burner has balance by definition, so exempting it would give spam a free pass through the one transaction type guaranteed to have funds.
  • The exactly-once check on redemption_ref shares its marker with Mint's credit_ref — one namespace, so a reference can't be reused across mint and burn either.

Exposed via the SDK/Hub API as createUnsignedBurn — see SDK API Reference and GraphQL Reference.

ChainInit (tag 9) — genesis only​

The single transaction in block 0. Carries every consensus parameter into state:

ChainInit {
  chain_id, is_testnet, tx_fee,
  ride_request_referrer_fee_bps, ride_offer_referrer_fee_bps,
  mint_authority, faucet_address, faucet_allocation
}

Its hash feeds the genesis block hash, and peers compare genesis hashes at the p2p handshake — a node configured with different values for any of these fields computes a different genesis and cannot peer with the rest of the network. ChainInit is rejected by validation at any height other than 0; it is never constructed by an app, the SDK, or the Hub API. See Node Configuration and CLT Economics.

Referrer fees​

On RidePay, the node distributes referrer fees from each payment installment:

  • ride_request_referrer_fee_bps (default 200 = 2%)
  • ride_offer_referrer_fee_bps (default 200 = 2%)

Fees use floor rounding (floor(fare × bps / 10_000)) — replacing the old ceiling rounding, which could inflate a fee on a tiny fare to a wildly wrong percentage. The driver always receives the exact remainder, so referrer fees plus the driver's share sum to the fare precisely, for every input.

The passenger is debited the full fare plus the flat tx_fee at RideAcceptance; RidePay credits the driver and referrers (and separately pays its own tx_fee to the block author) without debiting the passenger again for the fare itself.

Referrer addresses for new requests and offers are injected server-side by the Hub API from default_ride_request_referrer and default_ride_offer_referrer config.

See CLT Economics for the full payment flow, the peg, and examples.

Validator compensation​

There are no block rewards. Every non-exempt transaction (everything except Mint and ChainInit) pays a flat tx_fee (default 1000 CLT = $0.001) to the author of the block it lands in. See CLT Economics for why this replaced block rewards.

JSON-RPC methods (node WebSocket)​

The node exposes these methods at ws://host:port/ws:

MethodDescription
send_raw_transactionSubmit signed RLP hex
send_transactionSubmit structured tx object
get_next_nonceAccount nonce
get_account_balanceCLT balance
get_account_balance_effectsBalance change history
get_block_by_indexBlock lookup
get_chain_infoGenesis-committed chain parameters, total_supply, and latest_block_index
list_ride_requestsOpen requests (optional map bounds)
list_ride_offersOffers for a request hash
list_active_tripsIn-progress trips
list_completed_tripsFully paid trips
list_recent_tripsCompleted + cancelled

That is the complete list — any other method name returns a method-not-found error. Apps typically use the Hub API instead of calling the node directly. See JSON-RPC Reference for full request/response shapes, including get_chain_info's.