utilities with receipts

April 12, 2026

utilities are not sexy.

airtime. data. electricity tokens. cable tv.

high frequency. low margin. endless edge cases.

and that is exactly why they matter.

and yes, this is already live.

the contract is deployed on bsc mainnet and verified.

here is the on chain code: https://bscscan.com/address/0x12d024F861878627E98182df9Ae8fB8921Cc88C0#code

this is not a concept post. it's a receipts post.

the real question is never "can a user pay?"

the real question is "can you execute reliably, reconcile automatically, and get cheaper per transaction as volume grows?"

that is what we are building at celia.

fully tracked utility payments on chain, fully auditable order lifecycle, and celia token cashback only when the job is actually done.

why utilities punish sloppy systems

when you run utilities at any serious scale, volume does not just increase revenue.

it increases failure modes.

retries. provider timeouts. duplicate sends. refund requests. support tickets.

if your ledger lives only in your backend database, every new transaction is another row you must defend in arguments, screenshots, and "trust me" explanations.

and at scale, "trust me" becomes expensive.

because when a user says "my top up failed", nobody cares that your provider had an outage.

they want one thing.

proof.

the core idea: one ledger, one truth

our approach is simple on purpose.

put the payment and the order record on chain.

that chain record becomes the canonical receipt:

an order id. a buyer address. a token and amount. a utility type. a status that can be proven later.

the status is not vibes.

it is a lifecycle.

requested. fulfilled. failed. refunded.

now your finance team is not reconciling five internal tables and two vendor dashboards.

they are reconciling one ledger.

support is not guessing what happened based on vibes and screenshots.

they query the order status and the events.

audit stops being a hero story and becomes verification.

this is where economies of scale show up quietly.

as volume grows, reconciliation cost grows much slower than transaction count.

how we connect chain truth to real world fulfillment

blockchains cannot call telcos.

you cannot do http from a smart contract.

so the boundary is clear:

on chain handles value transfer and the auditable lifecycle. off chain handles fulfillment with providers.

the contract emits a purchase event.

the backend listens, treats the order id as the global idempotency key, calls the provider, and then finalizes the order on chain as fulfilled or failed.

that is not "less on chain."

that is the correct split of responsibilities.

if you want to see the paper trail, bscscan has it all:

- contract address: https://bscscan.com/address/0x12d024F861878627E98182df9Ae8fB8921Cc88C0 - contract events: https://bscscan.com/address/0x12d024F861878627E98182df9Ae8fB8921Cc88C0#events

idempotency is the difference between growth and chaos

most utility losses at scale come from duplicates.

the user retries. the backend retries. the provider retries. the network hiccups at the worst time.

so you need a structure that makes duplicate loss harder, not a policy that asks humans to be careful.

the contract anchors the order.

the backend uses that order id as the one key that cannot be faked across systems.

and the order can only be finalized once.

this is how volume becomes safer, not scarier.

pricing without oracle drama: signed quotes

we support multiple payment tokens.

but we price the utility in usd terms so it stays consistent.

instead of writing on chain oracle updates every time fx moves, the backend signs a quote per purchase.

the quote is bound to:

the buyer. the token. the rate. the expiry. a nonce to prevent replay.

this gives us flexibility without sacrificing integrity.

quotes scale with backend infrastructure, not with admin transactions.

and if someone tries to replay a quote or reuse it across wallets, it fails.

the quote is not a suggestion.

it is a signature bound to a specific buyer and a specific moment.

cashback that respects reality

we do not pay cashback because a user clicked a button.

we pay cashback when the order is fulfilled.

cashback is funded from the contract's celia token balance and paid only on success.

that small detail matters.

it aligns incentives with reliability.

it prevents "cashback on failed orders" leakage.

it tells the truth in code: reward execution, not intention.

and at scale, cashback becomes something else too.

it becomes demand aggregation.

the more utility spend routes through celia, the more celia distribution happens.

repeat usage increases. retention increases. customer acquisition cost per transaction falls over time.

that is the kind of compounding you want.

cashback is not just a marketing sticker.

it is a system rule.

"if the job is done, reward the user."

what a utility order actually looks like on chain

this is the part i love, because it removes storytelling from the equation.

each purchase becomes an order with an id.

you can point to it.

you can audit it.

you can build support and refunds on top of it without begging a database row to behave.

and when something fails, the system has a clean path:

fail the order. refund the user. let the user claim their refund.

no drama. no guessing. no "dm admin".

airtime and data are different, the pipeline is the same

airtime is amount based.

data is plan based.

but both map into the same primitive:

escrow. order id. event. fulfill or fail. refund when needed.

once that pipeline exists, adding new categories becomes less dramatic.

electricity. cable. anything that can be fulfilled off chain can inherit the same on chain order lifecycle.

the marginal cost becomes provider integration, not rebuilding payments and reconciliation every time.

what this unlocks later

once purchases are consistently on chain, you can build features that would be painful in an off chain only world:

verifiable receipts. deterministic refunds. partner settlement based on events. treasury ops that can be audited. risk rules anchored to facts.

and because the ledger is standardized, shipping those features gets cheaper over time.

that is the quiet advantage of doing the hard work early.

the point of all this

we are not putting telcos on blockchain.

we are putting the payment and the order truth on chain so:

reconciliation becomes simple. disputes become factual. duplicates become structurally harder. scale improves reliability instead of breaking it.

utilities are boring.

but boring systems run the world.

and if we can make boring reliable, auditable, and cheaper as it scales, then we have something bigger than a feature.

we have a foundation.

in a world of screenshots, be someone who ships receipts. in a world of hype, be someone who builds ledgers. in a world of doubt, be someone who fulfills orders.