Comments (7)
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.
Related Issues (20)
- CIP-1854 | Adjust preamble and structure w.r.t CIP-0001
- CIP-1855 | Adjust preamble and structure w.r.t CIP-0001
- Add References section to CIPs/CPSs HOT 10
- CIP-100: Make witnessing optional + add CIP-08 message signing HOT 5
- CIP-9999 | How to add Copyright to CPSs HOT 4
- CIP-0069: alternative approach HOT 10
- CIP-0072: Suggestions for improving dApp registration identity verification HOT 4
- CIP-100 | Canonical example is wrong HOT 3
- CIP 100 | Provide directions on how to create signatures for the body without circular dependencies. HOT 19
- Wiki: Initial topics + points to cover HOT 8
- CIP-0058: integers vs. byteStrings for cryptographic applications HOT 32
- Rendering errors on cips.cardano.org. HOT 2
- CIP-0013: Current state of integration and further advancements HOT 13
- CIP-0010 | Add schema links HOT 2
- Voter metadata sign the initial document HOT 1
- Tracking protocol parameters definitions HOT 3
- Indexing CIPs Repo for Core `Waiting for Implementation` proposals HOT 1
- CIP-0021 Transformation Breaks Script Integrity HOT 11
- CIP PR queue overhaul, state vocabulary & tagging HOT 10
- CIP-105 / CIP-1852: suggested HD paths incompatible with security policy of Ledger HWW for Conway roles HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cips.