Most token writeups start at the wrong end. They open with the price chart, then work backwards to a use case, then dress the use case in mission language. I want to do the opposite. I want to start with what the IMPT token does inside the IMPT platform on a Tuesday afternoon, when a guest is booking a room in Lisbon and a tonne of CO₂ needs to be retired against that booking before they check in. Everything else — the design, the supply, the wallet flows, the reason it exists at all — falls out of that single constraint.
Start with the constraint, not the coin
IMPT.io is a carbon-positive booking and shopping platform. We list 1.7 million hotels across 195 countries, and we work with more than 20,000 partner brands on the retail side. Every booking offsets one tonne of CO₂, on-chain, paid for by IMPT out of the commission the hotel or merchant pays us. That sentence is the entire product brief. The token has to serve it. If it doesn't, it's decoration.
So the constraint is this: a carbon offset has to be retired, verifiably, against a specific transaction, in something close to real time, at a per-unit cost low enough that a hotel commission can absorb it without changing the price the guest sees. That is a payments-layer problem dressed in climate clothes. It is not a trading problem. The moment you treat it as a trading problem, you've already lost the user, because the user does not want to think about any of this. The user wants a room.
What the IMPT token actually does
Inside the platform, the IMPT token plays three roles, and only three. I'll keep them short because they should be short.
- It is the unit of account for carbon credits on the platform. Verified credits from real-world projects are tokenised and held on-chain. When a booking completes, a credit is retired and burned against that booking. The retirement is the point. The credit cannot be sold again, used again, or laundered into a second claim. That property is hard to get with a spreadsheet and easy to get with a ledger.
- It is the settlement rail between the commission we earn and the credit we retire. A hotel pays us in fiat. We commit to retire a tonne. The token is what sits between those two events and makes them auditable. A reader, a regulator, or a guest can in principle trace from the booking to the retired credit without taking our word for it.
- It is the mechanism that lets a brand or a guest opt in to more. If a corporate travel buyer wants to retire above the baseline tonne — for an event, for a route, for a quarter — the token is the lever. They are buying retirement, not exposure.
That's it. There is no fourth role. We have been disciplined about that, because every time someone proposes a fourth role, it turns out on inspection to be a speculation feature wearing a utility hat.
Why it isn't a speculation vehicle, by design
People ask, fairly, why have a token at all. Why not just buy credits in the conventional voluntary carbon market, retire them against bookings, and post a PDF report each quarter. The honest answer is that the conventional voluntary carbon market is, in places, a mess. Double-counting, vintage games, projects that don't exist on the ground, retirements that nobody can verify because the registry is a website with a login. A public ledger is not a magic fix for any of that, but it does fix one specific thing: it makes the retirement event public, atomic, and replayable. You can argue about the quality of the underlying credit. You cannot argue about whether it was retired.
So the token exists for verifiability, not for upside. Several design choices follow from that, and they are the choices that distinguish a climate fintech token from a meme:
- The token's job is to leave the system. Every booking burns a credit. A token whose primary on-platform behaviour is being destroyed is not optimised for holders. It is optimised for the climate ledger.
- The user-facing surface hides the token. Guests booking a hotel on IMPT do not need a wallet, do not need to hold IMPT, do not need to know what a credit is. The commission absorbs the cost. The token is plumbing.
- The treasury policy is boring on purpose. We hold credits to retire against forecast bookings. We are not running a trading desk.
If you build the product this way, the token cannot really function as a speculation vehicle even if someone wants it to. Its main job is to disappear, one tonne at a time.
Climate as a payments-layer constraint
The phrase I keep coming back to, internally, is that climate is a payments-layer constraint. What I mean is: the climate impact of a transaction has to be settled inside the same flow as the money, on the same timescale as the money, and with the same audit guarantees as the money. If it lives in a separate quarterly report, it gets gamed. If it lives in a marketing deck, it gets ignored. If it lives in the payment rail, it gets paid.
This is the design lens we apply to everything on the platform. The IMPT Card, when a user spends, retires against the spend. The forthcoming AI-native booking agent, when it books on a guest's behalf, will retire against the booking the same way the website does today. The retail flow with our partner brands works the same way. The mechanism is the same in every case because the constraint is the same in every case.
It is not glamorous. Most of what we build is reconciliation logic, registry connectors, retirement queues, and the dull work of making sure one tonne booked equals one tonne retired equals one tonne reported. The token is the connective tissue across that dull work.
What this means for utility token design generally
I came to this from twenty years of engineering inside Tesco, Dunnes Stores, and Oracle, which is to say I came to it from systems that have to actually balance at the end of the day. There is a lesson there for utility token design that I don't see written down often enough, so I'll write it here.
A utility token is justified when, and only when, the alternative implementation is materially worse on a property the user or the regulator cares about. For on-chain carbon, the property is verifiable retirement. For payments, it might be settlement finality across borders. For loyalty, it might be portability across merchants. If you cannot name the property in one sentence, the token is decoration and you should remove it from the design.
The corollary: tokens whose pitch is "we'll figure out the utility later" are, in my experience, tokens whose utility was never the point. We chose to be specific about ours up front, even at the cost of looking dull next to projects with broader narratives. Dullness has compounded well for us.
Where the model breaks, and what we do about it
I want to be honest about the failure modes, because the worst version of an essay like this is the one that pretends the design is finished.
The model breaks when the underlying credit is bad. A perfect on-chain retirement of a junk credit is still a junk retirement. We deal with this by being selective about the projects we accept onto the platform and by publishing what we retire. It is a continuous diligence problem, not a one-time check.
The model also strains when volume scales faster than supply of high-quality credits. That is a good problem to have and a real one. Our answer is to keep the per-booking commitment fixed at one tonne, source against forecast volume, and refuse to dilute quality to hit growth.
And the model assumes that the chain it sits on remains a sensible place to record retirements over a long time horizon. That is a question I think more about than I used to, which is part of why Ireland Quantum, our sovereign Irish quantum compute facility committed for Q2 2027, sits next to IMPT in our group of companies rather than apart from it. Long-horizon climate ledgers and long-horizon compute infrastructure are the same conversation, viewed from two angles.
What to do this week
If you're a founder thinking about a token, write down in one sentence the property your token guarantees that a database cannot. If the sentence is hard to write, you have your answer. If you're a corporate travel buyer or a brand reading this, the practical step is to ask your current providers where their offsets are retired, when, and whether you can see the retirement. If the answer is a PDF, ask for the ledger entry. And if you want to see how this works in practice, book your next stay through IMPT.io and watch the retirement happen against the booking. That is the whole product, and the token is what makes it provable.