I’m a programmer who loves to make street art. I'm working on an NFT system that expands the functionality of BCH SLP thus avoiding the gas prices of ETH. I intend to work with the community to develop this system.
I'm calling it a Buyer Gift NFT (BGNFT?) and I'm using it to sell canvas implementations of my street art.

How Buyer Gift NFTs Work:

Every time the token is sold, I take 10%. If that’s $50 or more, I’ll ship the buyer a physical implementation of the asset. Limit 1 per person per week. $60 if non-US shipping.

My Plan:

I need to get feedback from the SLP community, particularly the developers of juungle.net, to figure out a good implementation for my Buyer Gift business model. So far, I can think of 2 ways to do it. I would love your feedback on my ideas.

Idea 1, Multi-Sig Wallets:

One way of implementing my model would be to restrict tokens I make to only be held in multi-signature wallets. My server would have a signature and the current owner would have one. I (the artist) would set up an API on my server to facilitate these wallets. The idea is that my server will only sign a transaction if I have been paid the 10% and if the recipient is also a multi-sig wallet of which it is a signatory.

When purchasing a token I made in a marketplace, buyers will be informed that they need to set up a special wallet to receive the token before they buy it. The marketplace can then use my API to generate the wallet internally. The buyer will either opt out of the gift or specify a shipping address in the wallet setup dialogue.

If the buyer wants the token sent to an external wallet the marketplace can check with my server if the destination is valid. Alternatively, the marketplace can just not do the check and leave buyer hanging but that wouldn’t be very nice.

My server will have instructions and human web interfaces for handling transactions between wallets outside of marketplaces.

Pros:

• The shipping address can be gathered when the wallet is set up.

• Works with existing systems. No SLP wallet or protocol change would be needed.

Cons:

• The artist’s server could be a point of failure.

• Dishonest artists could try to adjust their cut after the token is minted.

• Buyers wouldn’t have as much control over their tokens.

Idea 2, On-Chain Transactions:

Use Bitcoin Cash smart contracts to create UTXOs (unspent transaction outputs) on the chain which enforce the artist’s cut and maintain the contract. In this case my Buyers Gift NFT deal isn’t an essential feature but rather will be facilitated by instructing buyers to send me their shipping addresses in a signed message on the site linked in the NFT.

In this model users will track and buy NFTs on the blockchain through the wallet rather than marketplaces. I hope artists will be able to pay sites like marketplaces to list their NFTs and perhaps record user feedback ratings and other analysis. Otherwise, it could be hard for buyers to find NFTs for sale.

I've included some CashScript code in this article and some explanation of how it works. If you are a more casual reader, feel free to skim this briskly or even just scroll past it. I recommend picking up again at the Pros and Cons part at the end of the page.

The smart contract would have 2 functions:

• buy: Allows anyone to buy the NFT by paying everyone, changing the owner to themselves and setting a price.

• setPrice: Allows the owner to control the price as long as they are the owner.

The buy function insures there are exactly 4 outputs of the transaction:

• The new contract output with the new owner that anyone can get at the set price.

• The 10% artist's cut.

• The 90% previous owner's cut.

• The change which goes back to the buyer.

Here is the general idea of the code I’m proposing:

pragma cashscript ^0.6.0

contract NFT(

                bytes20 owner,

                int price,

){

                function buy(int newval,bytes20 buyer){

                                bytes newContract = 0x18 + newval + buyer + tx.bytecode.split(24)[1];

                                out1 = new OutputP2SH(bytes8(dust),hash160(newContract));

                                out2 = new OutputP2PKH(bytes8(price/10),ArtistKey);

                                out3 = new OutputP2PKH(bytes8(price - price/10),owner);

                                out4 = new OutputP2PKH(bytes8(int(bytes(tx.value)) - price - dust - 1000),buyer);

                                require(hash256(out1+out2+out3+out4) == tx.hashOutputs);

                }

                function setPrice(int newval,pubkey pk, sig s){

                                require(hash160(pk)==owner);

                                require(checkSig(s,pk))

                                bytes newContract = 0x04+newval+tx.bytecode.split(4)[1];

                                out1 = new OutputP2SH(bytes8(dust),hash160(newContract));

                                out2 = new OutputP2PKH(bytes8(int(bytes(tx.value)) - dust - 1000),owner);

                                require(hash256(out1+out2) == tx.hashOutputs);

                }

}

Pros:

• Buyers have full control over tokens.

• The contract is mostly implemented on-chain.

• Would require some ecosystem changes but at least it doesn't need a BCH fork.

Cons:

• Users would need to adopt new wallets.

• Will take substantially more effort to implement than the multi-sig idea.

• May cause mining fee bidding wars over competing attempts to spend a UTXO.

I'm eager to hear your thoughts!