Prepare for post-launch NFT artwork

[danielattilasimon]

Addressed in this PR

This PR addresses the following points of #118.

Not burning

The NFT is no longer burnt when terminating the bond (either through chicken-in or chicken-out). As a consequence, bond supply only ever increases. Bond data is no longer deleted either. This allows bond data to be used in the generation of metadata/artwork even after the bond is terminated.

Since the bond is no longer burnt, we need an alternative way of preventing multiple termination (e.g. chickening out twice). A new field status is added to bond data, which is checked and updated by chicken-in/out. The same field can also be used by the artwork to determine which kind of visuals to render.

Transfer lockout period

To prevent potential scams where the sale of an active bond (which holds additional economical value on top of the artistic aspect of the NFT) is frontrun by a chicken-in/out by the bond's owner, we disallow transfers of the bond NFT for a configurable period of time after chicken-in/out. To facilitate this, a new field endTime is added to bond data, holding the timestamp of the block which terminated the bond. The NFT artwork may also use this field as additional source of (weak) randomness in generating the chickened in/out visuals.

Upgradeable NFT metadata

The computation of tokenURI() is delegated by BondNFT to an external contract. When constructing BondNFT, an initial delegate may be provided as a constructor parameter. If left zero, BondNFT will initially return empty string as tokenURI(), until the final delegate is set. This lets us decide whether we want to provide some preliminary metadata even before artwork launch, or not.

A final delegate can be set (once) through setArtworkAddress(). Upon calling this, the owner of BondNFT loses ownership over the contract.

Left open

The following points are not addressed by this PR, as there are still open questions.

• Wrapper to terminate and transfer bond in one TX: we haven't decided whether this is worth it, or even if it's a good idea.
• Transfer fee: we haven't fleshed out the specifications for this. Would we only activate this once artwork is upgraded? Is there a de facto standard for implementing transfer fees? (I've found https://eips.ethereum.org/EIPS/eip-2981, but OpenSea doesn't seem to support it).
• Better source of randomness: currently, the only (weak) sources of randomness are the startTime and endTime of the bond, both of which come from block timestamps. If we want higher quality randomness, we should probably implement it ahead of artwork launch to avoid having a procedure for claiming the artwork.
• Placeholder metadata: we may want to launch with some preliminary implementation of metadata (tokenURI()) so that bond NFTs show up with some description (or even some basic attributes like bonded amount, creation date, termination date) in wallets and marketplaces. Since this is implemented as a read-only function in an external contract, it may not need to be thoroughly audited.

[bingen]

For the first pending issue, “Wrapper to terminate and transfer bond in one TX”, we decided not to do it, to prioritize security. The potential use cases of the wrapper don’t seem so important.

[bingen]

A note about transfer fee: We have to make sure that pending bonds can be transferred without a fee, otherwise the sale of NFTs for the economical value doesn’t make sense (the fee value would be higher than the value of the time / opportunity cost of the pending bond). The transfer fee would make more sense for chicken in state, which is expected to have more artistic value.