CIP-0027 | Smart contract royalty addresses about cips HOT 7 OPEN

This is a valid point. And I think its probably time to start adding handles to the royalty token as well. I'll probably look to make an update in the near term, where a few new tags are added:
'version': 2
'handle': $yourhandle #superceeds the addr if the marketplace supports it
'sc_datum': {your needed datum}

from cips.

@rphair Appreciated, thanks.

from cips.

Datum is already attached to transaction.
The only change we need is that we can attach Acceptor to each script address.
Existing script addresses would see no change - the default acceptor would be \_txn -> True.
But script addresses that can only accept certain transactions would be able to reject all others.

A lot of money lost with Eth and Tezos smart contracts can be attributed to overly liberal acceptance of money by these contracts.

For example Uniswap-style exchange can refuse any transaction that is not a valid
exchange of tokens for other tokens, or deposition of matching amount of tokens at the current price. It would also refuse accepting any tokens or NFTs that are outside trading pair.

Escrow smart contract in Ada would refuse acceptance of any tokens or NFTs.

Being an "honest banker" means we should refuse money when it is not ours.

Since this merits further discussion, I will create a separate CIP.

TBC: #472

from cips.

As part of writing CIP-88 I have been thinking about CIP-27 quite a bit wrt how we can expand and modify it to support receipt of payment at a smart contract which could provide much greater extensibility in terms of sub-dividing royalty payments to multiple recipients (while keeping the underlying spec for CIP-27 as simple as possible).

One though I had would be to expand the definition in the spec to declare the script reference and expected datum format such as:

{
  777: {
    rate: "0.05",
    address: ["addr1...","...xyz"],
    script: {
      referenceUtxo: "abc123...456xyz",
      datumFormat: [0,""]
    }
  }
}

from cips.

@Tenancio the best I can do with this is to tag the original authors & contributors to the discussion of #116: @huths0lo @matiwinnetou @gitmachtl @SebastienGllmt @Crypto2099 @KtorZ

Maybe after discussing a bit here you could submit either

• an update CIP for CIP-0027 (if there's a convergence on your suggestion or other straightforward alternative), or
• a CPS if it's a problem without a particular solution and/or a wider variety of approaches.

from cips.

Option would be to add an Acceptor script that only accepts valid payments.
Every eUTxO to a smart contract would have to call it in order to confirm that datum is acceptable.

from cips.

Option would be to add an Acceptor script that only accepts valid payments. Every eUTxO to a smart contract would have to call it in order to confirm that datum is acceptable.

I doubt there is a practical way to make that work at the moment. The marketplaces would need to be able to provide the necessary datum when sending to a smart contract. And theres no details within the existing standard that could provide that info to the marketplaces.

I'm not a plutus expert, but if there was a way to provide the needed "datum" within the 777 metadata, then it might be doable. I also think we need to add a "handle" tag, that would allow the usage of a wallet handle (obviously Ada Handle being the currently well known handle). The idea of using an asset as the identifier of the royalty wallet was proposed by @nicolasayotte way back when the original 777 standard was developed. This was well before Ada Handle existed. So I have to give him credit where credit is due.

Although I firmly believe that the royalty token should be minted as the first asset in a policy, and dont think that should change, I think its reasonable to be able to update the payout address. I know @Crypto2099 is currently working on a CIP for updateable metadata, as is nicolasayotte. And I also know CIP-086 is already in use. The crypto2099 design will have a link to an offchain oracle. This to me would be a very good option, since the royalty toke creator would specify their oracle. And that CIP offers an updatable design after policies have closed, and is backwards compatible. If that approach were to be taken, I think its reasonable to allow royalty tokens to be added to policies that were already in use at the block height where the 777 token was introduced (and maybe even a little after since it took time for the standard to be adopted).

from cips.