IFTTS

If This Then Sign (IFTTS) is a protocol to decentralize the trigger of operations based on multi-chain facts, using Threshold Scheme Signatures (TSS). The protocol supports the creation of accounts with their private keys distributed among a set of decentralized nodes. The accounts have a number of rules, coded on-chain but executed off-chain, that maps a list of blockchain facts (such as event X emitted on block Y) into a set of messages that must be signed by the nodes (if requested).

The Blockchain facts are events, calls, block data (such as number, timestamp, etc.), account data (balance, nonce), etc. from all the supported chains. It doesn't need to be the home chain where the IFTTS protocol lives.

When receiving a request to apply a rule and sign messages from a given list of facts, the nodes need to check the facts are true, apply the rule, and sign the message(s).

The protocol just produces ECDSA signatures, that can be later used in different ways and use cases. These signatures can produce EOA transactions, can be used with Account Abstraction, can just sign off-chain messages such as those of Push Protocol, etc.

Possible use cases:

• Bridges
• Alerts based on blockchain conditions (using Push Protocol).
• Copycat oracles (replicate price oracles on one chain into another chain).

The account creation, the definition of rules, and the disputes happen on-chain. The day-to-day signature happens off-chain.

The communication between the signer nodes happens on Waku (https://waku.org/), making this decentralized, fast, and cheap.

To avoid sybil attacks, we plan to use Polygon ID or another identity solution to make sure the nodes are controlled by different people. We also forbid that a single node takes more than one share in an account's private key.

For the dispute resolution regarding blockchain facts (if the signer nodes signed a message agreeing on a given fact but someone disagreed), we plan to use UMA.

The on-chain code is coded in Solidity. It includes three main contracts:

• TssAccountManager: this is the core contract that manages the created accounts and the list of rules connected to them.
• NodeRegistry: this is a registry of the nodes that are allowed to sign.
• DisputeCourt: this contract will handle disputes on potential misbehavior of the nodes.

Presentation slides: https://docs.google.com/presentation/d/1PMni0tJfGiYef_Tfw8JIf8CPye-GbfTKjro37uLzhJQ/edit?usp=sharing