Multi-chain contexts

Each agreement can define a context, which indicates which rules it falls under and also which court resolves the dispute. The context (and correct me if I’m wrong) can be any contract that implements a particular court interface and is able to produce outputs that indicate its rulings.

But behind the scenes, this contact could easily use an oracle or any other method to interface with another court contract on another chain, therefore providing scalability and possibly different levels of immutability or state transition algorithms for different courts.

Of course then the issue is reputation and how to trace back reputation to the jurors, since reputation would be likely kept in the chain where the Supreme Court lives. Thoughts?

1 Like

But behind the scenes, this contact could easily use an oracle or any other method to interface with another court contract on another chain, therefore providing scalability and possibly different levels of immutability or state transition algorithms for different courts.

This is true. Though in practice I expect it makes sense for a given court to exist on a single chain (or shard) as I expect that significantly simplifies the implementation of reputation and other mechanisms.

So the advantage here is you could have agreements on multiple chains shards, that all reference the same arbitration mechanism (court) that may exist on a completely difference chain/shard.

1 Like

Exactly. This would also make possible situations where you can create binding agreements between multiple chains that have different VMs or ways of encoding smart contracts. Wouldn’t be as smooth as a smart contract, but makes inter-chain agreements possible without even having compatible VMs.