# Cross-chain automatization

## Absctact
Bridges and bridge systems are gradually appearing in blockchains, which so far can only make a simple transaction of one of two types:

1. Transfer between a pair of chains directly
2. Transfer between a couple of chains through a blockchain intermediary ([Sifchain](https://sifchain.finance/))

Complex or conditional (with conditions when to perform this or that action) cross-chain transactions do not yet exist.

There is something similar to complex transactions in instant loans - [Flash loans](https://aave.com/flash-loans/), there is even a convenient automation of a complex Flash load by the [Furucombo](https://furucombo.app/combo).

The closest to the idea project is [defihelper](https://defihelper.io/no-code) ([Intro](https://www.youtube.com/watch?v=5tUnwK77y8c)). Hovewer, they don't have or plan to hace a trustless protocol, parallel transactions, cross-chain transactions and the ability to make complex automation code with Solidity.

On the other hand, trading automation has long grown into a big industry like in classical exchanges in the form of high-frequency trading [HFT](https://www.iflr.com/article/2a646mpixhlq5fir64agw/primer-high-frequency-trading), and in private investments in the form of financial management bots.

Smart contracts were born as a means of managing finances. But they are limited to one blockchain. You can go a step further and create a smart contract management service across multiple chains.

Let's call this new thing Higher order smart contracts.

## vs smart contracts
1. A smart contract can't call itself, or call itself on a certain event. Hosc can
2. Things like 'best price between chains A, B, C" cannot be programmed in smart contracts. In HOSC it's possible
3. hosc can have any offchain events like Nasdaq rate, TVL change for any contract, time before the Merge
4. Smart contracts have to be public. Hosc is not.
5. As far hocs is private we can build a referral system for them. Eg. I can make a hosc, have a referral link to it to ask more users to participate in the hosc for some interest. And so on and so forth.
6. A technical one. There is no good way to execute smart contracts in parallel, which defines capacity of the network. Hosc are independent from Ethereum or whatever state, and we can scale their execution as we 'd like to.
7. As a result I hope to build cross-chain arbitrage community.

## Chain or chainless
We believe not all users need a blockchain. No one would like to publish their's trading strategies. For that kind of customers we started with the most difficult part, with chainless solution, but keeping all security properties via TSS cryptography.

For DEXes or users that needs public verification, we are going to introduce DAGbased chain.

## For whom and for what purposes?

### DeFi

#### Arbitrage
DeFi projects such as UniSwap, xDai, Compaund rely on arbitrage as what gives stability and security to the system. So Compaund puts a part of the outstanding debts at a discount on the sale in order to avoid a full default on debts. The debt discount has created an arbitrage market that tracks profitable debts for sale.

#### Yeild Farming
By providing tools to automate cross-chain transactions, we are creating a new market for profit - Yeild.

### DEX
[Limit order](https://www.investopedia.com/ask/answers/04/022704.asp) has long been one of the most important parts of the DEX. For example in 1inch [limit order protocol](https://docs.1inch.io/docs/limit-order-protocol/introduction/).

The service for creating managing contracts(HoSC) will be able to cover the needs for a Limit order for any DEX(in that terms HoSC platform could be offered to any DEX without limit-orders) and provide much more, for example, create a Limit order that does not withdraw money to a wallet, but transfers it to [DAI](https://makerdao.com/ru/), or in [Compaund](https://defirate.com/ctokens/#:~:text=cTokens%20are%20a%20back%2Dend,a%20corresponding%20balance%20in%20cTokens.) when the market falls.

### Trading bots
While we do not know about cross-chain trading bots, there are separate solutions where you need to trust the bot code and it is very limited in its actions. In addition, you need to hire a programmer to write and run the bot. In this sense, HoSC provides both the ability to automate without a programmer and the contract execution infrastructure.

**_Research is required here, whether there is such a thing in conventional finance. And if not, then why._**

Nothing prevents us from creating a platform for registering bots, maintaining their rating, and advertising.

### Limit order
I, as a user, want to delegate the ability to buy / sell a token at a price that I set one-time.

### Regular transactions at the set rate
I, as a user, want to be able to automate my regular operations, develop trading strategies, and create referral programs from my strategies to sell them to other users for use.

### Other buying and selling algorithms
Purchasing definitions:
* best price - buy at the best available price
* limit order - buy no more than the specified price
* market order - buy at market price
* stop market - if the price rises to the specified level, then buy at the market price
* stop limit - if the price rises to the specified level, then place a buy limit order
* take profit - if the price drops to the specified level, then place a buy limit order

### MEV protection

### Pathfinding/routing
In the future, it would be cool to provide your API Pathfinding/[routing](https://help.1inch.io/en/articles/4585131-what-is-routing) to be called like an oracle in a managing smart contract. This will allow you to make more trading bot strategies. It is the same as taking a fee for using pathfinding.

## About finality
We do not have to make events only when finalization is reached, we can make two types of events for pending and finalized changes. And let the user choose how to build the logic of the control contract.

## About state and concurrent execution
For pure functions, there is no state problem and, accordingly, they can be easily executed concurrently.
State machines can be limited to only one write or read-only control contract.

## What are our profits?
Fixed price for each step of the control transaction and for each crossing of bridges if our DEX is used.

## What are the types of management contracts?
1. One-time. When you need to execute a chain of actions once
2. Regular. When you want to do it multiple times

## Development steps
0. HOSCs can be made in 2 versions as a state machine with the state of the control contract, as an actor model of pure functions that accepts various events. At first, it is easier to make an actor model from pure functions. Stateless HoSC has the advantage that such contracts can be executed by Oracles simultaneously, in parallel.
1. Cross-chain bridge (in development, there is a version working on testnets. No integration into HOSC)
2. Creation of a control contract (made as an actor model without a state, an example of a limit order contract was made):
2. Lists of handled events and handler functions.
3. A library for connecting to Solidity contracts [DSL](https://en.wikipedia.org/wiki/Domain-specific_language) to add the logic of various smart contracts that you want to follow.
4. Examples of HOSCs
5. Using validators (oracles) you can manage user contracts without the need to transfer funds to system contracts. The user only provides Approve in terms of ERC-23 for the required number of tokens to manage (done). After the oracles read events from the chains (this part has already been done), form a transaction for the user contract (through their partial signatures and achieving consensus), send the transaction to the target chain (done for Ethereum).
7. Integrate DEX
8. Integrate routing
9. HOSCs as referral programs

## Roles
1. Oracle
* Tracks events in other chains
* Receives HOSC user contracts and keeps them, passing copies to other oracles.
* Fulfills HOSC user contracts by reaching consensus with other Oracles.
2. Bot and online HOSC constructor
* Visual designer of the HOSC schema, which is then translated into Solidity code and passed to Oracle
* Personal account of referral programs
3. User
* Creates/Changes/Stops HOSC with desired conditions
* Pays for HOSC execution to execute cross-chain transactions

**_There is a suspicion that tracking events will not be easy. It should immediately be thought out close to optimal. However, this is a task that can be solved on a large scale, since all block explorers do exactly the same thing: they monitor events in blockchains and process them, making them searchable. In our case, the task is simpler - we don't need a search._**

## A HOSC example
At the moment a simple HOSC already works on our testnet with Ethereum testnets:

contract HighOrderContractOneChain {
    struct Action {
        string name;
        Token token1;
        Token token2;
        address to;
        uint64 targetChain;
    }

    struct SubscribeParams {
        Token token1;
        Token token2;
        uint amount1;
        uint amount2;
    }

    struct Token {
        address addr;
        uint64 chainID;
    }

    function Main(Token[] memory _tokens, address _to, SubscribeParams[] memory _params) public pure returns (Action[] memory actions) {
        if (_params[0].amount1 <= 30){
            actions = new Action[](1);
            actions[0] = Action("SwapV2", _tokens[0], _tokens[1], _to, _tokens[1].chainID);
            return actions;
        }

        if (_params[0].amount2 >= 40) {
            Action[] memory actions = new Action[](1);
            actions[0] = Action("SwapV2", _tokens[1], _tokens[0], _to, _tokens[1].chainID);
            return actions;
        }

        return actions;
    }
}

One can create it's version of the HoSC with a call to one of Oracles, prividing pair of tokents to subscribe to. As a next step we'll generalise PoC to use any supported blockchains, contracts and events of them to write HoSC on Solidity. Also, one of the main goals is to have simple Telegram bot and online HoSC constructor like [Furucombo](https://furucombo.app/combo).

## Security
We use no blockchain for HoSC, the trust is all on Oracles that have shares of approved by users keys, hence to owning user funds. For, as well as [Thorchain](https://thorchain.org/) - [TSS](https://gitlab.com/thorchain/tss/tss-lib/) and Binance [TSS](https://github.com/bnb-chain/tss-lib/) . The base paper is [GG20](https://eprint.iacr.org/2020/540.pdf).