Considerations
- The travel industry is made of a multitude of suppliers and connecting to each and every of them is very long as they are diverse in terms of APIs, payment methods, …. We need a unified way to connect to all possible suppliers, including future ones. For all participants, this should be a “Integrate Once, Connect Many” model.
- Current access to suppliers is gated mostly for financial reasons, suppliers must be guaranteed to get paid for the booking they do. The usage of tokens allow a trust-less relationship between buyer and supplier, opening new use cases.
- The volume of queries in the travel industry is very high and as suppliers provide richer and richer offers, the metadata is increasing. At the same time, the speed is expected to be very fast or otherwise customers would drop-out.
Proposal
This page proposes a centralized (initially), yet permission-less solution for travel industry as a Layer 3 network.
The aim is to provide an RPC compatible with the Ethereum JSON RPC so that the Winding Tree network can be added easily in MetaMask (for end-users) or Ethers.js (for applications). Using the Ethereum Smartcontract infrastructure (ABI, typing, events), it allows enforcing a common schema while reducing the time to market.
It is proposed that the operator of the solution is appointed by the Winding Tree DAO on a yearly basis. Different operators might take over in the future if the DAO decides it.
Transactions on the Winding Tree network are paid in LIF as the native token of this network. It is suggested to have a fixed cost (in USD terms) depending on the operation type so that it is more predictable for businesses operating on the platform. Fees amount can be voted on by the DAO. The fees are collected by the DAO that can allocate budgets to R&D, Operations, Marketing and strategic partnership.
Concerns
- Centralization: It is acknowledged that this solution is currently centralized. This is mostly for performance and time to market reasons. There are different de-centralization paths: 1) Single-Operator: the DAO can appoint another operator. The RPC endpoint can be in an ENS record to enable it to change. 2) Multi-operator: It is be possible in the future to have multiple node operators synchronizing with a consensus algorithm. However the resources/GDPR requirements make it nonviable for small operators. Note that popular L2s such as Starknet and zkSync are centralized and have plans to decentralize in the future. It is also not uncommon to have DAOs appointing external companies, see for example AAVE/Gauntlet.
- Tokens/Bridge Trust: Users are trusting the WT Bridge to work in both ways. This is a difficult problem to solve as we have seen many bridges being hacked in the last couple of years. This is a bit mitigated by the fact that funds can be bridged “just on time” and only for a single transaction if needed. It is not the aim to have a high TVL on WT network. Significant security assessments must be performed in any case, and a solution similar to ZkSync “Exodus” should be put in place.
- Network Switching / UX: Switching between networks can be painful for users when using directly MetaMask.
Functional View
Technical view
