Trustless BTC-ETH exchange.

Problem

Bitcoin Mirror + BtcTxVerifier lets you prove that a transaction sent X sats to Y address.

This means that Silver Portal cannot allow two open escrows owing the same amount to the same address.

Say two people hit the same bid in equal size; the market maker is offering to buy 1 BTC, and two traders each want to sell them 0.1 BTC. This creates two escrows that owe the same amount to the same address. We can't distinguish these transactions; trader A sends 0.1BTC, trader B simply reuses the same proof to close their escrow as well, cheating the exchange.

Possible solutions

1. Add data to the Bitcoin transaction. Trader includes the escrow ID as extra data in the Bitcoin transaction.

2. Commit to send from a particular UTXO. This is uglier, but can be done without custom Bitcoin script; the trader says "I will close escrow from this UTXO", making their transaction proof unambiguous.

3. Track kekkak(recipient, amountSats), do not allow two open escrows to collide.

Option 1 feels least hacky. Unfortunately, though, the UX of Bitcoin wallets is extremely primitive. There is nothing like Metamask, no way for an application to propose a Bitcoin transaction for a user to approve.

Option 2 also suffers from lack of support--as far as I can tell, there is no clean way with popular Bitcoin wallets to create a draft transaction, such that you know which UTXOs will be used in advance.

Option 3 works with existing Bitcoin wallets. It requires a compromise on the exchange UX, either:

• "Sorry, there's already a pending escrow for 0.1 ETH to this recipient. Pick a different amount", or
• Automatically pick a different amount that is one or a few sats higher. The escrow interface then tells you to send this exact amount. If you send 0.10000001 BTC, you close your own escrow; if you send 0.1 BTC, you close someone else's.

Current

• Prices are stored in tokPerSat, so we're pricing bitcoin in terms of an Ethereum-based token (either WBTC-wei, eth-wei, ...)
• However, "buy" means buying the other thing and paying in Bitcoin

Proposed

• Buy / bid buys Bitcoin
• Sell / ask sells Bitcoin
• Either way, the Bitcoin is priced in tokens; tokPerSat

We can achieve this by renaming the contract (buy/sell) and (bid/ask) functions, then updating Exchange.tsx and child components.

we already have CI for deployment thru Cloudflare Pages

now we need CI for unit testing

cd packages/portal-contracts && forge test --vv
cd packages/portal-web && npm ci && npm test

Goal

• Display liquidity concisely
• Prevent 1-upping; if the best bids are at 0.999 WBTC/BTC, you shouldn't be able to place yours at 0.99900001

Possible implementation

Add an owner-settable parameter, tickTokPerSat. In the deploy script, we can default it to 1000000, corresponding to a minimum tick of 0.0001 WBTC.

Add validation to placeAsk/placeBid. The price must be a multiple of tickTokPerSat. This is the only place where we should validate--that way, if we change the tick in the future, any existing orders remain valid, the rule only applies when adding liquidity. (Currently = posting a bid or ask. In the future, if we allow adding liquidity to an order, it should also check there.)

Add randomization to the frontend. During a buy or sell, we match with the best order that's large enough to accomodate the order size; but if there are multiple such orders, we want to pick one at random. Unclear whether we want to weight by size, there's arguments each way, so we can start out by doing it the simpler way--no weighting.

In pseudocode...

const orders = isBuy ? asks : bids; // either way, ordered best to worst
const matchableOrders = orders.filter(o => o.size > tradeSize);
if (matchableOrders.length === 0) throw new Error();
const bestPrice = matchableOrders[0].price;
const bestOrders = matchableOrders.filter(o => o.price === bestPrice);
const orderToFill = bestOrders[(Math.random() * bestOrders.length) | 0];

An aggregate list of potential improvements to consider, pending user feedback etc.:

• [ ] Allow updating an existing order
• [ ] Specify a min fill for an order (such that the minimum fill for an order > tx costs of completing the partial fill)

Everything in the order the same besides updating stake/amountSats. Would be a UX improvement for mm bots, vs creating another order, or there being an order with dust in it so not worth closing out

for the proof of concept, we have just one pair: ropsten ETH / testnet BTC.

for production, we can have ETH / BTC, but also others:

• WBTC / BTC . decentralized, without Wrapped's onerous onboarding process. the spreads here should be much tighter than what's possible on ETH/BTC.
• ETH / ZEC
• WZEC / ZEC