crossclaim / xclaim-sol

XCLAIM(BTC,ETH): Solidity implementation for Bitcoin backed tokens on Ethereum

XCLAIM(BTC,ETH)

Disclaimer: this project is still under development and not safe to use!

Overview

XCLAIM is a framework for achieving trustless and efficient cross-chain exchanges using cryptocurrency-backed assets (CbAs). XCLAIM allows to create assets which are 1:1 backed by existing cryptocurrencies, without requiring trust in a central operator. While this approach is applicable to a wide range of cryptocurrencies, we currently focus on implementing Bitcoin-backed tokens on Ethereum, i.e. XCLAIM(BTC,ETH).

XCLAIM introduces three main protocols to achieve decentralized, transparent, consistent, atomic, and censorship resistant blockchain interoperability for cryptocurrencies:

• Issue: Create Bitcoin-backed tokens on Ethereum.
• Swap: Swap Bitcoin-backed tokens on Ethereum with Ether.
• Redeem: Burn Bitcoin-backed tokens on Ethereum and receive Bitcoins in return,

The current XCLAIM prototype is compliant with the ERC20 standard. An overview of the protocols is presented below:

XCLAIM guarantees that Bitcoin-backed tokens can be redeemed for the corresponding amount of Bitcoin, or the equivalent economic value in Ethereum. Thereby, XCLAIM overcomes the limitations of centralized approaches through three primary techniques:

• Secure audit logs: Logs are constructed to record actions of all users both on Bitcoin and Ethereum.
• Transaction inclusion proofs: Chain relays are used to prove correct behavior on Bitcoin to the smart contract on Ethereum.
• Over-collateralization: Incentivize honest behavior following a proof-or-punishment approach. All involved parties must actively prove correct behaviour to the smart contract, e.g. by providing inclusion proofs for Bitcoin transactions.

Paper

Read more about XCLAIM in our paper (currently under submission).

Protocol Summary and Components

A concise overview is coming soon. For now, please refer to the paper.

API

Coming soon. For now, please refer to the paper.

Installation

Make sure ganache-cli and truffle are installed as global packages. Then, install the required packages with:

npm install

Testing

Start ganache:

ganache-cli

Migrate contracts:

truffle migrate

Run tests:

truffle test

This will also re-run migration scripts.

xclaim-sol's Issues

Add postconditions as "assert" to each function

Revert if an assert fails.
Check if necessary for all functions

Allow vaults to specify dedicated accounts+values which are allowed to issue with them

Benefit:

• DoS protection / white listing
• Allow vaults to reserve collateral to issue tokens themselves (without being charged an additional fee obviously)

confirmRedeem - create new event, in case verifications failed

confirmRedeem - add missing pre-condition checks

• can only be called by a vault
• check digest is in OP_return

confirmRedeem - release vault collateral functionality

"Unlock" vault collateral.
Add boolean flag to decide if

1. Collateral remains in contract and is available for new issuing processes
   or
2. Collateral is send back to vault's account.

Heed Help: config for btc private network

Hi there!

I want to try to swap btc to eth on private network. In the repo I can not find where to set up and config btc private network. Can you kindly give me any clue?

Thanks!

issueToken: add separate function for vault to claim collateral/fee for failed issue commitments

redeem process - add replay protection

Add replay protection to redeem protocol, to prevent a vault from re-using the same Bitcoin transaction as proof for multiple redeemRequests.

Require the following digest is included in OP_RETURN of the redeem Bitcoin transaction:

• redeemer Eth address
• contract address
• redeemRequestId

split redeem proof handling into proof submission by vault and reimbursement claim by user

issueToken and registerCommit must only be called by same user account

Problem: if we do not check that the same user account is used to call issueToken, as registerCommit, the vault or a malicious user can call issueToken for arbitrary users with wrong data, causing it to failr (and collateral being slashed).

Solution: check that msg.sender is the same user that called registerCommit in issueToken

reimburseRedeem - implement reimbursement functionality

Required checks:

• Redeem must be free! i.e., vault cannot charged a fee for this
• User specifies bitcoin transaction fee? Challenge: if too low, tx never included. Who is to blame then? Problem!
• We might need an oracle for current bitcoin transaction fees.

--> if BTC relay is used frequently, we can use verified TX as an estimate

Support for multiple issuers

We need to implement support for multiple issuers. Currently, it seems as if only a single issuer can register.

registerIssue: allow a user to issue multiple commitments simultaneously

Currently a user can only create a single issue commitment at a time.
Problem: mapping currently is msg.sender => CollateralCommit
Fix: increment a uint256 counter with each commitment and use the following mapping:
hash(msg.sender, counter) => CollateralCommit.

Challenge: user must track hash(msg.sender, counter)!
Fix: emit msg.sender and the counter non-digested

replaceRequest - replay protection

Add replay protection - identical to issue and redeem:

• contract address
• redeem request id/nonce

requestRedeem - specify vault and check if it has sufficient funds

Currently, no vault specified when making a redeem request.

Problem: vaults can prevent users from redeeming funds if they do not react -> however, we will not know who to punish.

Fix: add vault address as parameter.

Check required: does vault have sufficient funds?

Merge vault collateral for issuing or large amounts

To allow issuing of large tokens amounts within a single issue process --> allow multiple vaults to join collateral (user driven call!).

Integrate automatic doc generation for APIs

Automatically generate API docs with: https://github.com/OpenZeppelin/solidity-docgen

replace failed - slash old vault's collateral if replace not executed after lockReplace

Replace new vault's tx fee?

issueToken - add more detailed error handing + return to user

postpone redeemRequests created during existing replace lock

When a redeem request is created after lockReplace has been called, the countdown of the redeem request must only be initiated AFTER the replace was finalized.

lockRedeem must fail if there are pending redeem requests for that vault

Otherwise, the new vault may end up having not enough time to fulfill the redeem requests and get's punished

add vault fee deduction

Write up all pre- and postconditions for methods + double check require/assert statements

lockReplace - add surplus collateral to vault's collateral balance

Problem: currently surplus collateral given to the contract

Fix: add the surplus collateral to the vault's balance

requestRedeem - add "fill up" flag

Instead of users having to enter the precise amount of the vault's available BTC, when they want to redeem a large sum with multiple vaults, allow user to specify a "fill up" flag, which simply takes all of the vault's available funds.

Improvement: we avoid dust remaining in the vault's balance.

getter - get used collateral per vault

issueToken: implement replay protection for BTC lock transaction

Problem: transaction can be replayed by a user to trick contract into issuing multiple tokens, possible with different contracts

Fix:

• Contract must check that contract address is in Bitcoin transaction -> prevent issuing on multiple issuing chains
• Contract generates a nonce which must be included in the Bitcoin tx -> counter

As a result, the contract returns a digest of:

• user eth address
• contract address
• counter

Collateral for issue commitment should depend on the amount (and duration?) locked by the user

Define a factor: eth collateral per vault's locked collateral unit (eth) per time unit (minutes / blocks).

issueToken - where to send slashed collateral?

Currently, slashed collateral is paid to the vault, whose funds were locked.

Problem: may incentivize vault to try to force failures.

Alternative: burn? Keep in contract?

Other option: make vault reimbursement strictly smaller than the fee the vault would earn in case the issue would succeed

registerIssue: Update check for free vault collateral to consider expired commitments

The check for free vault collateral must also check for expired collateralized commitments.

Reason: otherwise, the vault would have to make a transaction to update the balances when a commitment expires (and user did not issue).

TODO:

1. add additional method extracting correct amount of free vault collateral and marking it as free (stateful!)
2. Getter method for free collateral must extract all expired commitments as well (stateless). Do the check/calculation in the frontend / offchain to save gas! (get all vaults and all existing commitments)

replace - add partial replace

Cancel collateral issue committment if exchange rate drops to much

If the exchange rate drops so far, the vault's collateral falls below a certain threshold (specify!) --> allow the user to abort the issuing process without penalty.

issueToken: emit transaction ID instead of transaction header