Skip to content
A smart contract and arbitrate oracle service on LightningNetwork
Branch: master
Clone or download
Latest commit a9d9609 May 13, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs Update workflow image May 13, 2019
lightning-proto add sign rpc. Apr 17, 2019
scripts/lnd Remove deprecated files May 8, 2019
thor-app Show error message. May 10, 2019
thor-arbitrate-service remove cert files. May 10, 2019
thor-core Fix empty list issue May 10, 2019
vm-service Add opcode 3 for getWinner May 9, 2019
.gitignore add ignore Apr 3, 2019 Update workflow image May 13, 2019
build.gradle test and warn. May 9, 2019
gradlew add test Apr 3, 2019
gradlew.bat init project Apr 2, 2019
settings.gradle remove client project. May 8, 2019

Thor - A smart contract and arbitrate oracle service on Lightning Network


Thor is a bitcoin layout 2 implement base on Lightning Network, users can develop smart contract with WebAssembly on it and we also implement a arbitrate oracle service to guarantee trustworthy of the applications running on it. Project is under heavy development, not production ready.

Inspiration of the name "Thor" comes from the Germanic mythology which is the god of lightning.


Since bitcoin network does not have a mature layout 2 smart contract implementation currently, Thor is a experimental project for it. The smart contracts on Thor are compiled to WebAssembly, and the arbitrate oracle service is a hash time locked contract implementation through Lightning Network. Developers can write the smart contract by implement the interface of the thor contract abi.


+------------------+                   +--------------------+
|  Thor client     |----StatesManage---|  thor Arbitrater   |
+------------------+                   +--------------------+
|                  |----Arbitrate------|                    |
|  Smart contract  |                   |  Smart contract    |
|  Vm (WebAssembly)|   	       	       |  Vm (WebAssembly)  |
+--------+---------+                   +---------+----------+
         |                                       |
         |                                       |
         |                HTLC                   |
              |    Lightning Network      |

How Thor works

Assume Bob and Alice want to play Gomoku throw Thor, the workflow is below

  1. Authorization Both of the game client Alice and Bob request arbitrate service to generate a nonce with signature, then sending back that nonce with their signature after verifying the nonce with the public key of arbitrate, after the arbitrate verified those signatures, the authorization finished.

  2. Create game room Alice request arbitrate service to create a game room and join it then waiting for Bob to join by giving the room id to him.

  3. Funding btc for game

    1. Arbitrate service generated a pair of (r, rhash) for both Alice and Bob and just giving the rhash to them.
    2. Game clients connect to the LN node, exchange the invoice which generated with the rhash by INVOICE_DATA, then pay for the invoice.
    3. Both game client confirm the state of their invoice is ACCEPTED.
  4. Play game

    1. Arbitrate service will broadcast a GAME_BEGIN message to the room after the READY message beening sent from all game clients in the same room.
    2. Game playing will be proceed through runing the witness data in vm which generated by both game clients and arbitrate service.
  5. Finish game and challenging

    1. If someone surrender to another, just finish peacefully.
    2. both clients can request a challenge with the proof of data during a challenge period.
    3. The arbitrate serivice will replay the game by running the proof data in vm after a challenge recived and find the winner.
    4. The winner will get the "secrect" r of the loser to unlock the funding btc in lightning network after the broadcast of arbitrate. If tie happen, the r would not be broadcast, and both clients cancel the invoice payed before. After all, game end.


You can’t perform that action at this time.