One of the main motivations for the development of mercury layer (from the original mercury statechains) is the fact that the operator is blinded: they don't and cannot know anything about the coins (or even if they are coins) - it just stores key shares and updates them in accordance with the protocol.

This does put the operator in a very good legal position as opposed to say, a custodian. But ultimately there is nothing stopping a government from doing whatever they want - and could make such a thing illegal (but IMO this would be like making cloud providers and KMS illegal).

But crucially, even if the operator gets shut down, all owners get their coins after a timelock with the backup transaction.

There are several possibilities. One is that you could use a statechain to send someone a pre-funded channel off-chain (so instantly usable). Another possibility is that different LSPs could use it to rebalance channels to manage liquidity better, without having to go on-chain.

The backup transactions have an absolute timelock - so there is no way a previous owner can broadcast before the timelock. If the operator is shut down, the owner needs to be online when the timelock becomes valid.

This is quite good: https://bitcoinmagazine.com/technical/mercury-layer-a-massive-improvement-on-statechains

But as a quick ELI5-ish:

An address (public key) is created from two private key shares - one from the server/operator and one from the owner. Bitcoin deposited to this address is the 'statecoin' - it can only be spent with a signature generated from both the server and owner cooperating.

The server and owner cooperate to sign a 'backup transaction' spending the BTC to an address of the owner, which will become valid after a future timelock. So if the server disappears, the owner will still get their money back.

To send the statecoin to a new owner (receiver), the current owner gets the public key of the new owner (this is the mercury address). They then sign a new backup transaction paying to the new owners pubkey, but with a timelock that expires some time sooner than the first one (so it becomes valid sooner). They then get an encrypted random number from the server, and add their private key to it. They send this and data about all previous signatures and backup txs to the receiver (they don't have to send directly, can relay via the server an encrypted blob).

The receiver then verifies all previous signatures and backup txs, and check this matches the number of signatures the server reports it has previously co-signed for this shared key. They add their private key to the encrypted key value and send back to the server.

The server then updates it's private key share with this blinded key value. The server private key share now only combines with the new owner private key share to be able to co-sign for the statecoin pubkey (which doesn't change). The old owners private key share isn't valid any more - and no-one has learnt the full private key at any point.

So long as the server:

The transfer has then completed off-chain and completely privately.

Here's how I understand it right now:

I make an onchain transaction to a new address that has the following properties:

Is this how it works?

Cool - thanks.

We are working on a GUI wallet for desktop and android (and then later on ios) - should be ready for in a month or two. Swapping will work a bit differently and be peer-to-peer. With the blinded server only a single swap is required for complete privacy.

Effectively instant. Each send requires 3 rounds (3 server calls by the client) and negligible computation. This is a few hundred milliseconds over clearnet, a couple seconds over Tor.

Receive is only 2 calls, but you have to verify the full chain of signatures, but still less than a second.

I will say it is definitely 'not' custodial, IF the server is honest. I recognise that in the world of bitcoin the word 'non-custodial' has a specific meaning - so that why we usually use 'proactively non-custodial' - if the server has been proactive (i.e. honest in the past) it has no ability to steal in the present.

It is certainly non-custodial from a legal/regulatory perspective.

But we are very explicit about the trust model. Regarding SGX, this is layered below that fundamental trust. There are many protocols that rely entirely on SGX (i.e. it is the only line of defence) - this is risky IMO: we know it can be compromised (with difficulty).

We are using it as an additional layer to secure our deployed service, like how any company (e.g. Liquid) uses HSMs.

For mainnet there will be a fee to create a shared key (i.e. deposit a coin) which can be paid via LN. After that all transfers are free. This is similar to an opendime, where you buy the device initially and then all other use is free.

I hope he comes back to answer, because I'm very interested.

One thing though-- the "safety" mechanism for unilateral exit (you to get your Bitcoin back if you don't trust the statechain) is an HTLC that would create a transaction on the blockchain. So it may be that your exit destroys the dust you were trying to consolidate (or rather, it all goes to fees).

investors and income from previous projects.

Ark is in principle trustless, while mercury layer is not.

Both operate with fixed value coins, and have timelock based lifetimes.

Arc requires capitalisation for each transfer, so if a 1 BTC coin is going to be transferred 100 times, the ASP needs to lock up 100 BTC.

APO and CTV (with LN stuff) could

this is good resource https://bitcoinmagazine.com/technical/mercury-layer-a-massive-improvement-on-statechains

Otherwise come chat in telegram group: https://t.me/mercury_layer

This is the major limitation (only sending full UTXOs) which makes it not a great solution for general, or retail, payments. You could imagine a change/swapping feature (like paying for things in cash, using different denomination coins and getting change) - but the UTXO model doesn't work well for small amounts in a high fee environment.

The whole UTXO model does lend itself to some use cases though - the first was coinswaps for privacy. Others are things like gift cards, casino chips (for online gambling maybe). Also (bit controversial) NFTs and ordinals - at least these could be transferred off-chain (reducing on-chain bloat).

Unlike LN, there are no inbound or routing liquidity issues and large amounts can be sent to anyone instantly. So one possibility is wallets that handle both LN and mercury - payments could automatically be made in a combination with the bulk that that's too big for LN sent via mercury fixed values and the remainder with LN.