(inspired + extract from Calypso paper)

Properties

Auditability: All data accesses are third-party verifiable and recorded in a tamper-resistant log.

Decentralization: There are no single points of availability failure or security compromise in the system.

Confidentiality: Secrets stored on-chain can be decrypted only by authorized clients after leaving an access record.

Fair access: Clients are guaranteed authorized access to a secret after posting a valid access request on-chain. If a barrier point exists, authorized clients atomically get simultaneous access after the barrier, protecting against front-running.

Future: Receiver anonymity: An on-chain proof-of-access log does not identify the user unless an audit is requested.

Future: Dynamic self-sovereign identities: Users and organizations fully control the public keys representing their identities, and can update them verifiably and atomically.

Fair Exchange of private data (not just tokens)

1. Alice publishes onchain an encryption of XXX (maybe with a zkSNARK of correct encryption of some properties on the message, like it’s being signed by President YYY)
2. Bob gives money on smart contract
3. Smart contract orders decryption to the threhsold network to Bob’s public key

Access Control

(Generalization of the above^)

Organization A wants to share with organization B a document D whose entirety or certain parts are classified and should be accessible only by people with proper clearance. Clearance is granted to (or revoked from) employees individually as needed or automatically when they join (or leave) a depart- ment, so the set of authorized employees continuously changes. The goal is to enable the mutually distrustful A and B to share D while dynamically enforcing the specific clearance requirements and securely tracking accesses to D for auditing

Zero Collateral Lottery or Sealed bids auctions

1. Participants registers as participants, encrypt their “lucky number” to the threshold network key.
2. At the barrier point, no more registration is allowed
3. Network decrypts all tickets from participants, winner wins the lottery.
1. Variant works with “bets” where the highest bid wins the game, there is no choice to withdraw, no collateral needed.

More fair cross-chain exchange

There are many ways of doing this, with different levels of complexity and security guarantees. See this page for a more detailed discussion of the problem and how Medusa could be used to help. However in all cases the overall idea is to utilise a holding contract on all chains in question, which is administered by a threshold signature held collaboratively by the servers in the Medusa network. The following is the simplest MVP case.

1. Clients will transfer a large amount of tokens (some of which they they wish to exchange) to the administration contract on the chain in question. At the same time they post a threshold encryption of their order information (i.e. amount they wish to exchange, and to what tokens and to what address).
2. At a certain point in time the servers then decrypt the new orders and based on the orders an liquidity of the holding contracts, compute the market clearing price.
3. The servers then threshold sign the exchanges that must be carried on each holding contract on each chain and post the orders to each of these holding contracts.
4. The holding contracts send the appropriate funds to the clients.

Oblivious (non) membership

Set-membership and set-non-membership are two essential operations that comes up a lot, both on the internet and in web3. For example the need to validate that a certificate/public key has not been revoked or that a user hold a credential on an approve-list. Such operations are easy to do in plain in a compact manner e.g. through a Merkle-tree or simply a hash map. However, in many situations we might wish to be able to do this in a privacy preserving manner. For example if someone wants to prove to a smart contract that they are part of an approved set, without leaking which entry on the approved set they fulfil.

This might be possible to achieve through the use of a secret shared algebraic accumulator and lightweight MPC as suggested in this paper. The paper unfortunately does not solve the issue of efficient updates of sets, which would be needed for many use-cases. However it is probably possible to do, as discussed here

If this gets implemented concrete use-cases include the following:

1. Obliviously checking if certificates have been revoked.
1. This does not need to be x509 certs, but could just as well be used to check if wallet addresses have been added to a ban-list.
2. Oblivious authentication
1. In the web 2 setting it could be used to have a user prove they have access to certain data/services, without having to leak their identity or account information.