Almost every technically curious investor we’ve sat down with asks some variant of the same question in the first ten minutes.

“You’re using your own oracles? Why not just plug into Chainlink?”

It’s a fair question. Chainlink is by far the dominant decentralized oracle network. They have a strong reputation, a serious security record, and a broad developer ecosystem. Going off-script costs us something. So why did we?

The short answer: hospitality has needs that general-purpose oracle networks weren’t built to serve well.

A quick primer, for anyone who doesn’t live in this stuff

A smart contract is code that runs on a blockchain. It can hold assets, enforce rules, and release payments based on conditions. What it cannot do, natively, is know anything about the outside world. It can’t read a hotel’s availability calendar. It can’t see the current exchange rate. It can’t verify that a guest actually checked in.

An oracle is the bridge between the blockchain and reality. It feeds external data (prices, events, verification, identity) into smart contracts so they can act on it. If the oracle lies or breaks, the contract acts on bad information. Which is why oracle design is one of the highest-stakes problems in blockchain engineering.

What we needed our oracles to do

Tratok’s smart contracts handle a lot of decisions every day. Refunds, booking confirmations, dynamic pricing, dispute resolution. Each one needs trusted external data:

The trade-off, framed honestly

General-purpose oracle networks are designed for general-purpose data. They optimize for breadth (price feeds for every asset, every chain) and they’ve done a brilliant job of it. But that breadth means they’re necessarily one or two abstraction layers above the specific domain logic we needed.

For us, that gap turned into three real problems:

Latency. A booking decision happens in seconds. A guest is on a page, they click, they expect a confirmation. Round-tripping data through a general-purpose oracle network adds latency we couldn’t afford for the hot-path operations. We needed sub-second response times on availability and pricing queries.

Cost at scale. Every oracle call has a cost. For a platform that’s aiming at millions of transactions per month, paying per-query fees to a third-party network would have inverted our economics. The savings we’re giving back to providers and consumers depend on keeping the unit cost of every transaction near zero.

Domain customization. A “property check-in confirmation” isn’t a standard oracle primitive. Neither is “dispute arbitration on a partial refund.” Building those on top of a generic feed network is possible, but you end up writing so much custom logic around the oracle that you’re effectively running half of one anyway. We decided to just write the whole thing.

What we built instead: GHOST

GHOST is our proprietary oracle protocol, purpose-built for hospitality and travel data. The name stands for nothing pretentious; it’s short and our backend team liked it.

A few things GHOST gets us that general-purpose oracles can’t:

• Sub-second hot path. Availability and pricing queries return in milliseconds because they’re native to the system, not bridged.
• Domain-aware data structures. The protocol speaks “booking,” “rate plan,” “cancellation policy,” “check-in event,” not just generic numeric feeds.
• Cost scaling. Marginal oracle cost approaches zero at high volume, which is the only way provider savings of 28 to 36 percent are sustainable.
• Multi-source aggregation. GHOST aggregates inventory and pricing from our network spanning thousands of properties. The aggregation logic is tuned for the hospitality use case specifically.
• Independent audit. The whole system has been through independent security audits as part of our broader smart-contract review process.

What we gave up

I want to be honest about this. Going proprietary isn’t free. We accepted three real costs:

We don’t get the network-effect security of a large decentralized validator set out of the box. We compensate with audits, multi-signature governance on the protocol, and a continuously updated bug bounty program, but it’s a different trust model. We acknowledge it openly.

We carry the engineering load. Every protocol upgrade, every security patch, every new data type. That’s on our team. With Chainlink, a lot of that heavy carrying is shared across the ecosystem.

We don’t get free interoperability with the broader DeFi ecosystem. If we want to integrate with a DeFi protocol that expects Chainlink feeds, we have to build bridges. We’ve done some of this already and will do more.

The bet, in one sentence

For a platform whose core value proposition depends on near-zero marginal transaction cost and millisecond-class booking decisions, owning the data layer was the right trade. Even with the engineering load that comes with it.

That bet might not be right for every blockchain project. For a DeFi protocol or a synthetic asset platform, the answer is almost always Chainlink. But hospitality is a domain with such specific data needs, and such specific economic pressure to keep unit costs low, that the calculus changes.

If you’re working on something where you’re weighing a similar decision, we would be happy to compare notes. The crypto ecosystem doesn’t talk about this trade-off enough.

— Carol

Community Manager, Tratok