TelePORT
A non-custodial & trustless cross-chain assets transfer protocol.
Why?
There are around 1M tokenized assets on the Arweave network. This is just a tip of an iceberg as native tokenization is a relatively new concept and there are much more valuable pieces of data present on the chain that could potentially be tokenised and made transferable.
Arweave is great at collecting and storing valuable content. However, it’s less mature in terms of the availability of the trading infrastructure. First of all, there is very little liquidity as the AR cannot be directly used in smart-contracts and there are no tokenised stable coins available. Moreover, there is also a lack of other financial tools such as exchanges and lending protocols that usually help to bootstrap the market and price discovery mechanism.
Building the basic trading infrastructure from scratch is a long and challenging process. Liquidity usually goes to places where there are mature defi protocols that generate yield, but defi protocols require liquidity to function properly. This chicken and egg problem is usually resolved by injecting an initial portion of liquidity into external sources. However, in the bear market where there is a shortage of liquidity the process could be even more challenging.
The idea behind Teleport is to leverage the liquidity available on external networks and use it to trade content available on Arweave.
Challanges of cross-chain transfers
Partly covered in the next section, here’s a brief summary:
- Existing Bridging solutions
- Security issues (hacks)
- Liability with the custody of bridged assets
TelePORT
Teleport proposed a new standard for cross-chain asset transfers.
Contrary to typical bridges that connect two networks, teleport could handle connection between Arweave and any of the monitored chains simultaneously. The scaling depends on the implementations of chain monitoring on the side of asset sellers and could be easily extended with the help of Oracle services.
The biggest risk of using cross-chain bridges is caused by the need of locking assets at one-side of the bridge in order to receive mirrored assets on the other side. This creates a large repository of locked funds which is often a honeypot for hackers increasing incentives for finding even the smallest vulnerabilities in the bridge implementation. Teleport doesn’t hold any assets for a period longer than the transfer execution. Moreover, even during that period assets could be put in a segregated self-custodial contract that will be fully owned by users participating in the trade.
Another vulnerability of current bridges is their centralised nature which is reflected by the fact that all users are dependent on a set of validators nominated by the bridge owner. In our protocol we leave users the freedom to independently monitor the contract state on other networks individually reacting to the changes. They are able to delegate this responsibility to an external Oracle but we don’t impose any restrictions and different users may select different oracle providers or even perform the monitoring manually.
How it works?
TelePORT (Price, Offer, Reply, Transfer)
Transferring assets consists of a few steps described below. At the beginning let’s assume that there is a “Seller” who owns an asset on the Arweave chain and a buyer, who is willing to buy the assets with funds held on a EVM chain (e.g. Polygon).
In the first step, the seller announces the willingness of selling the asset by posting the price using a Warp smart-contract. After posting the price asset is locked for a certain period of time and cannot be transferred.
The buyer is watching for all interactions in the Warp contracts matching the price announcement pattern. If he finds the price attractive and wants to proceed, he must lock the corresponding amount in a smart contract specifying the seller account as the only recipient. The funds could be unlocked with a secret chosen by the buyer, and the hash of the secret must be published in the contract that locks the funds.
The seller must reply to the offer, acknowledging that the funds are properly locked with his address set up by the buyer. The confirmation is executed by setting up the buyer address as a recipient of an asset on Arweave and locking the transfer with the same secret that unlocks the payment.
After the hashlocks are set on both sides, the buyer may trigger the asset transfer by revealing the secret.
Implementation
Using Warp contracts, assets are temporarily locked at a stated price using a hashed secret. Unlocking occurs when the secret is revealed or after a set lock period, permitting re-locking with a new price. All assets can be secured in a single contract for cost-effectiveness, or kept in dedicated smart-contracts for added security.
An EVM equivalent contract is necessary for escrow functions.
The protocol requires one contract to be notified about changes of another contract deployed on a connected network. However, it doesn’t specify any mechanism for such monitoring. In the simplest and most decentralised case any user is free to manually observe a state of another network and accordingly update the state of his contract. Since such a solution is not very convenient and scalable, it’s been made possible to delegate monitoring to an Oracle service with the restriction that the delegation process is at the user’s discretion.
🛠️ The implementation
Think you’d be the right person to turn it into a fully functional app?
📩 Hit us up!
