WBCH - BCH wrapped as cash token

It’s wrapping season :gift:, and I made a simple contract to wrap BCH. It’s also online for testing at https://wrapped.cash

pragma cashscript ^0.9.0;

// Wrap BCH as tokens
//
// Transaction form:
//      Inputs: 00-covenant
//      Outputs: 00-covenant
//
// Author: Dagur Valberg Johannsson <dagurval@pvv.ntnu.no>
// License: MIT

contract WrapBCH() {

    function wrapOrUnwrap() {
        // Enforce that this contract lives on
        require(tx.outputs[this.activeInputIndex].lockingBytecode
             == tx.inputs[this.activeInputIndex].lockingBytecode);

        require(tx.outputs[this.activeInputIndex].tokenCategory
             == tx.inputs[this.activeInputIndex].tokenCategory);

        require(tx.inputs[this.activeInputIndex].tokenAmount + tx.inputs[this.activeInputIndex].value
            == tx.outputs[this.activeInputIndex].tokenAmount + tx.outputs[this.activeInputIndex].value);
    }
}

I’m looking for review of any possible issues with it :slight_smile:

edit: The contract has been deployed in address p0ujgnc9jnyurzv99678fgac3fdrq8x3py9rlrg6dlnz96qxrdl02efwc0sf

4 Likes

In private conversation, @bitcoincashautist has done a quick review and pointed out an interesting edge case:

As deployed, there are 21 utxo’s available to wrap/unwrap. It’s possible for a miner to deplete 20 of the 21 utxos for sats, which would require next person to use them to pay an extra 800 sats for DUST.

2 Likes

Interesting, that you do not constrain token category to any specific id.

1 Like

If someone sends a wBCH fungible token to the contract with a similar category ID, it would live on the contract forever, unless someone exchanged it off for BCH.

A category id if block could allow other tokens to be “cleaned” off the contract.

What is the upgrade or migration pathway for users with gen zero tokens?, The next contract honors any user exchanging tokens from ff4d6e4b90aa8158d39c5dc874fd9411af1ac3b5ed6f354755e8362a0d02c6b3 ?

Saves some bytes :-). We can reuse the same contract to create more variants too. How about a “Christmas 2023 limited edition WBCH” that only wraps 10 BCH at most?

If someone sends a wBCH fungible token to the contract with a similar category ID, it would live on the contract forever, unless someone exchanged it off for BCH.

A category id if block could allow other tokens to be “cleaned” off the contract.

Are you thinking it should have a “anyone can spend” path to recover if someone makes a mistake and sends a different token to the contract?

What is the upgrade or migration pathway for users with gen zero tokens?

Opt-in migration path would be to unwrap the BCH and wrap it in the next version of th contract

Untitled Diagram.drawio

2 Likes

Yeah, I had clean-up spending paths for Emerald DAO too, however I’m now starting to think it’s not worth the effort because having an “oops” path will make the contract heavier for regular users, and regular users would be interacting through dapps anyway so it’s unlikely a mistake ever happens to them (unless some bug in the app).
How often would it happen that someone erroroneusly sends BCH or tokens to an address? Is having a recovery path worth the contract being heavier and more complex for regular users?

They can just unwrap to BCH and wrap with the new wrapper? If everyone does it then all of the 21 wrapper UTXOs would go back to their initial state: holding just (21 * dust) of BCH + entire supply of the tokens.

I say this both as a joke, but also kinda seriously, I’d like to see WBTC on BCH. Propose to BTC maxis that BCH be it’s L2 solution lol

3 Likes

If this is all for fun and learning, then Carry on!! and ignore this question.

Question: is there any benefit of having sats-as-fungible-tokens over actually having sats on BCH?

2 Likes

It lets BCH be used in contracts that want tokens, like this (not so useful) BCH/WBCH trading pair

3 Likes

More generally it lets contract authors focus on just one interface (OP_UTXOTOKENAMOUNT) for interacting with both tokens & WBCH, as opposed to dual-interface where you’d need some OP_IF + OP_UTXOVALUE to handle BCH.

By wrapping BCH, the contracts can have a smaller footprint and be less complex, however the trade-off is that some complexity is then offloaded to users who have to go through wrapping/unwrapping.

3 Likes

IMO the benefit for a DEX would be that a contract can be made for the general case where tokens are traded against tokens, then you do not need to design a 2nd contract for the token/BCH case.

I disagree that it would be simpler to have a token-token pair in a DEX as you would need at least 2 token holding covenants to enable 2 way swaps, where as with token/BCH pair both can be held on a single UTXO.

2 Likes