What happens if there is an error while creating the new contract / burning the old one? Can that process be secure enough so that materially valuable assets be entrusted to use that process?
Yes, that would be very bad and likely destroy the asset. I will be doing more research into how error prevention is handled in existing contracts that generate further contracts. I would like to know more about formal verification - can this be used to ensure that the contracts will be guaranteed to recurse? I welcome any comments from developers with relevant experience here.
Very interesting, looking forward to seeing the details when the deep dive appears.
What is the reason for recursively launching a new contract? Is it not possible to achieve the desired effect by keeping track of durations for tidemark auctions, time between auctions, etc.?
Thanks! Yes this is a great question and there is likely better way to implement this - I have a lot to research and learning to do on this and welcome comments and criticism from those with relevant expertise.
My (naive?) understanding at this point is that once smart contracts land on the chain they are immutable, and so once they resolve (say when a tidemark auction concludes with a sale) they cannot be edited but only burned and a replacement generated. It would certainly be easier and more efficient to do this all in a web 2 style database, but one of the criteria is to avoid this kind of centralisation. Open to alternative solutions!
Ah, I see, so sounds like whether there's recursive launching or some other mechanism instead would end up being an implementation detail.
I'm more familiar with Solidity contracts on Ethereum but I *think* this could be accomplished in a single contract there. Things might be different on Tezos though, but I thought the contracts there have modifiable storage too.
I've done a tiny bit of smart contract coding but only recreationally, so can't really visualize what the contract here might look like. Do you mind if I take an exploratory stab at coding your idea in Solidity? (No worries if you'd rather I didn't! I'm not sure I will be able to come up with anything anyways....)
Go for it! Please share any progress here, or link to github or similair! I haven't used Solidity but I've heard its similair to JS which I'm decent with so I should be able to follow.
I am following some projects on Tezos but have only just started exploring the tech in any detail - I didn't know modifiable storage was a thing, but it already sounds like it could be a better implementation, just from the name! If it is a standard blockchain building block, Tezos probably has it, but I'll investigate.
Awesome to know that some others are interested in this idea!
With automatically entering NFTs into auctions, I wonder if this might be annoying for NFT owners who know they want to hold an NFT indefinitely. Perhaps there should be a way to automatically pay the fee? Or pay it should it be below as certain level (to avoid paying extraordinary amounts). Basically, a sort of backstop to avoid losing an NFT you desire to keep (maybe you are unexpectedly unavaillable around the time of the auction).
I absolutely agree with this - I am sure marketplaces and wallets would be quick to offer this service if even if it were not built into the protocol directly. There would also likely be some time period during which the owner could make their decision (possible set by creator at time of minting) This might be 1 hour or 6 months. Not sure what the right length of time would be for this. The longer it is, the worse outcome we might expect from the auctions.
More broadly, you are right in pointing out that there a loss of some control over the asset here from the collector. However, this must be weighed against the cost of other approaches. Other proposals for on-chain enforcement result in collectors losing or limiting the ability to transfer their asset to a cold wallet (because this would trigger a royalty payment). Or they require centralisation where collectors hand ultimate control of their asset to a marketplace or custodian, and we are back in Web2 land. There may be better solutions - I will be tracking these development - it looks like there will be quite a few proposals in the coming weeks from various actors.
It is also worth looking at some of the other upsides of the automatic auctions - for example: if the private key to a wallet is lost, or the owner passes away, the NFTs within that wallet would be lost to future collectors, and the artists will recieve no more royalties. Under this sytem, those NFTs will be recovered from the wallet via these automatic auctions.
Yes, this is a reasonable feature, to want to set some funds up to cover extra royalties so you can relax about losing ownership unless it's at a price you're happy about.
Some thoughts about it -- I think it works if the extra royalties get paid immediately to the creator, and then the current NFT owner gets an IOU from the contract for that portion of the royalties in the event of an auction creating a new high price (instead of the creator getting that portion, since they already got it).
However if the current owner wants those funds to sit in the contract just in case, ready to be deployed to retain ownership when needed, then I think it creates a disincentive for anyone to bid between the current tidemark price and the higher price implied by the funds set aside, so creators might not like that.
If the set aside funds could be kept secret then that might work, though I'm not sure how difficult that is to implement. Or as Grum mentions a marketplace or wallet could provide this service too, outside the protocol.
Decided to go ahead and deploy something. Many aspects of it are half-finished but progress was slow enough I figured I better deploy pronto or risk never sharing anything (kept getting hung up on frontend things; and irl demands intensifying).
Minting period lasts approx. 4-5 more days (free+gas to mint), then the cycles start: 1) interim stage (things work like normal NFTs), 2) bidding period for the tidemark auction, 3) grace period when current owner can pay royalties if necessary -- all 1 day each, then repeats.
Open for anyone to try it out but be aware bugs likely, try at own risk, recommend burner MetaMask even though it's testnet.
Finally, no worries if you're too busy to try it out / engage much -- I'm swamped myself these days so totally understand. Just wanted to get the thing out.
Finding it challenging to model the moving parts here, so just going to think out loud a bit about some scenarios to check if I'm understanding correctly.
Suppose Alice owns an NFT that she purchased at auction or minted for 10 XTZ. Between tidemark auctions, she can still sell to Bob at, say, 2000 XTZ. This is an "under the table" sale and no royalties are paid. However, presumably Bob feels (or felt) the NFT is worth 2000 XTZ or so. When it's time for the next tidemark auction (which can't verify the authenticity of this 2000 XTZ sale), if the winning bid is 50 XTZ Bob will certainly want to pay royalties on that price and retain ownership. If the market roughly agrees with Bob about the value, say with a winning bid of 1800-2200 XTZ, then Bob will have a somewhat tougher decision to make about whether to pay royalties and retain ownership.
Similarly, if Alice's 2000 XTZ sale to "Bob" had been a wash trade, this might partially be evident in a disparity between the price for that sale and the price people are willing to pay in the auction with royalties. If Alice had tried to execute that wash trade on-record in the tidemark auction, it would at least be more costly due to the royalties.
Exactly! Also worth pointing out that (assuming Bob understands the rules of the contract) he believes he is buying a token that comes with 199 XTZ of debt packaged in (at 10% royalty), so hopefully he factored this into the price he bought it at. There is nothing to stop Alice misleading him about this in the current version of this idea.
What happens if there is an error while creating the new contract / burning the old one? Can that process be secure enough so that materially valuable assets be entrusted to use that process?
Yes, that would be very bad and likely destroy the asset. I will be doing more research into how error prevention is handled in existing contracts that generate further contracts. I would like to know more about formal verification - can this be used to ensure that the contracts will be guaranteed to recurse? I welcome any comments from developers with relevant experience here.
The tweet here https://twitter.com/ArthurB/status/1659972821794136064?cxt=HHwWgIC9vZGftIkuAAAA from Arthur got me wondering whether this recursive royalty proposal interacts with account abstraction; I've no particular insight to offer on it, but wanted to flag this as possibly something to look into.
Very interesting, looking forward to seeing the details when the deep dive appears.
What is the reason for recursively launching a new contract? Is it not possible to achieve the desired effect by keeping track of durations for tidemark auctions, time between auctions, etc.?
Thanks! Yes this is a great question and there is likely better way to implement this - I have a lot to research and learning to do on this and welcome comments and criticism from those with relevant expertise.
My (naive?) understanding at this point is that once smart contracts land on the chain they are immutable, and so once they resolve (say when a tidemark auction concludes with a sale) they cannot be edited but only burned and a replacement generated. It would certainly be easier and more efficient to do this all in a web 2 style database, but one of the criteria is to avoid this kind of centralisation. Open to alternative solutions!
Ah, I see, so sounds like whether there's recursive launching or some other mechanism instead would end up being an implementation detail.
I'm more familiar with Solidity contracts on Ethereum but I *think* this could be accomplished in a single contract there. Things might be different on Tezos though, but I thought the contracts there have modifiable storage too.
I've done a tiny bit of smart contract coding but only recreationally, so can't really visualize what the contract here might look like. Do you mind if I take an exploratory stab at coding your idea in Solidity? (No worries if you'd rather I didn't! I'm not sure I will be able to come up with anything anyways....)
Go for it! Please share any progress here, or link to github or similair! I haven't used Solidity but I've heard its similair to JS which I'm decent with so I should be able to follow.
I am following some projects on Tezos but have only just started exploring the tech in any detail - I didn't know modifiable storage was a thing, but it already sounds like it could be a better implementation, just from the name! If it is a standard blockchain building block, Tezos probably has it, but I'll investigate.
Awesome to know that some others are interested in this idea!
Started this now at my sourcehut account: https://git.sr.ht/~jooxe3ri/tidemark-nft-contracts
Already learning a lot just trying to code this!
Awesome! I'll check it out.
Just fyi moved this to GitLab at https://gitlab.com/jooxe3ri/tidemark-nft-contracts since SourceHut is banning crypto projects.
Still a messy work-in-progress but I'll let you know once the contract gets to being an actual ERC721.
Super! will certainly report back and share here whatever I'm able to code up. With JS familiarity you will follow Solidity just fine.
Yup, modifiable storage is a thing, but it can really run up the gas fees so people always try to minimize its use.
With automatically entering NFTs into auctions, I wonder if this might be annoying for NFT owners who know they want to hold an NFT indefinitely. Perhaps there should be a way to automatically pay the fee? Or pay it should it be below as certain level (to avoid paying extraordinary amounts). Basically, a sort of backstop to avoid losing an NFT you desire to keep (maybe you are unexpectedly unavaillable around the time of the auction).
I absolutely agree with this - I am sure marketplaces and wallets would be quick to offer this service if even if it were not built into the protocol directly. There would also likely be some time period during which the owner could make their decision (possible set by creator at time of minting) This might be 1 hour or 6 months. Not sure what the right length of time would be for this. The longer it is, the worse outcome we might expect from the auctions.
More broadly, you are right in pointing out that there a loss of some control over the asset here from the collector. However, this must be weighed against the cost of other approaches. Other proposals for on-chain enforcement result in collectors losing or limiting the ability to transfer their asset to a cold wallet (because this would trigger a royalty payment). Or they require centralisation where collectors hand ultimate control of their asset to a marketplace or custodian, and we are back in Web2 land. There may be better solutions - I will be tracking these development - it looks like there will be quite a few proposals in the coming weeks from various actors.
It is also worth looking at some of the other upsides of the automatic auctions - for example: if the private key to a wallet is lost, or the owner passes away, the NFTs within that wallet would be lost to future collectors, and the artists will recieve no more royalties. Under this sytem, those NFTs will be recovered from the wallet via these automatic auctions.
Yes, this is a reasonable feature, to want to set some funds up to cover extra royalties so you can relax about losing ownership unless it's at a price you're happy about.
Some thoughts about it -- I think it works if the extra royalties get paid immediately to the creator, and then the current NFT owner gets an IOU from the contract for that portion of the royalties in the event of an auction creating a new high price (instead of the creator getting that portion, since they already got it).
However if the current owner wants those funds to sit in the contract just in case, ready to be deployed to retain ownership when needed, then I think it creates a disincentive for anyone to bid between the current tidemark price and the higher price implied by the funds set aside, so creators might not like that.
If the set aside funds could be kept secret then that might work, though I'm not sure how difficult that is to implement. Or as Grum mentions a marketplace or wallet could provide this service too, outside the protocol.
Decided to go ahead and deploy something. Many aspects of it are half-finished but progress was slow enough I figured I better deploy pronto or risk never sharing anything (kept getting hung up on frontend things; and irl demands intensifying).
So here it is, frontend live at https://3d6nft.com, code for UI at https://gitlab.com/jooxe3ri/3d6-nft-ui.
Contract is on Ethereum's Goerli testnet here
https://goerli.etherscan.io/address/0x929d9fd46953aff3e30fd86baf88d8e4572d0e0e.
Contract code at https://gitlab.com/jooxe3ri/tidemark-nft-contracts.
Minting period lasts approx. 4-5 more days (free+gas to mint), then the cycles start: 1) interim stage (things work like normal NFTs), 2) bidding period for the tidemark auction, 3) grace period when current owner can pay royalties if necessary -- all 1 day each, then repeats.
Open for anyone to try it out but be aware bugs likely, try at own risk, recommend burner MetaMask even though it's testnet.
Finally, no worries if you're too busy to try it out / engage much -- I'm swamped myself these days so totally understand. Just wanted to get the thing out.
Finding it challenging to model the moving parts here, so just going to think out loud a bit about some scenarios to check if I'm understanding correctly.
Suppose Alice owns an NFT that she purchased at auction or minted for 10 XTZ. Between tidemark auctions, she can still sell to Bob at, say, 2000 XTZ. This is an "under the table" sale and no royalties are paid. However, presumably Bob feels (or felt) the NFT is worth 2000 XTZ or so. When it's time for the next tidemark auction (which can't verify the authenticity of this 2000 XTZ sale), if the winning bid is 50 XTZ Bob will certainly want to pay royalties on that price and retain ownership. If the market roughly agrees with Bob about the value, say with a winning bid of 1800-2200 XTZ, then Bob will have a somewhat tougher decision to make about whether to pay royalties and retain ownership.
Similarly, if Alice's 2000 XTZ sale to "Bob" had been a wash trade, this might partially be evident in a disparity between the price for that sale and the price people are willing to pay in the auction with royalties. If Alice had tried to execute that wash trade on-record in the tidemark auction, it would at least be more costly due to the royalties.
Exactly! Also worth pointing out that (assuming Bob understands the rules of the contract) he believes he is buying a token that comes with 199 XTZ of debt packaged in (at 10% royalty), so hopefully he factored this into the price he bought it at. There is nothing to stop Alice misleading him about this in the current version of this idea.