Since every implementation will require buying SOUL and then buying the generator token, an interface for this would be generic across implementations.

Hey everyone.

Here's an open discussion. I'm not 100% convinced that the generator (and its hash) be chosen simply by the highest amount of staked soul tokens. The current approach outlined in #3 is the following:

The highest amount of soul token staked to a specific generator hash is the one chosen to generate the art.

The issue with this is:

1. The incentive to take on the opportunity to cost to stake towards a new hash needs to be such that the belief is in doing so, will generate enough new income for the artist such that its worth the opportunity cost. This opportunity cost is the cost of keeping one's own soul tokens illiquid. Other participants gain from this as well and thus the opportunity cost might be quite high ("Why would I stake to change the hash if everyone else can just claim rewards for it whilst I undertake the cost for doing so?").

2. Low staking will mean that the generator hash could change quite often. This makes it hard to implement the generator into the front-end fast enough if the hash does change. Adding a threshold is just arbitrary and hard to determine what would be meaningful in this context.

3. A generator hash can be chosen that can't actually be implemented. This can break the autonomous artist. Due to the low potential threshold in doing this, it could be griefed quite easily or even accidentally.

The goal of this discussion is to determine how we approach generators in general with artonomous. There's several variants that can be taken that differ in complexity.

The core choices are:

1. Hard-code to one generator OR
2. Allow multiple generators at the same time (with its own incentive games).

1) Remove the ability to upgrade/change the generator.

This is purely for simplicity reasons. A generator is chosen before hand and is hardcoded for this specific autonomous artist. If a different generator will generate and sell more art into the future, then one can simply fork this project and create a unique curved bond for that specific art bot.

The gains in simplicity of implementation & user experience design though dilutes the value prop of a self-improving artist. It also loses network effects around this specific autonomous artist.

2) Allow any amounts of generators.

If we assume that multiple generators will come to exist if this project is successful (forking, remixing, etc), then we might as well aim to allow multiple generators from the start. Instead of having multiple artists with their own curved bonds, we aim to build it such that there's a network effect around multiple generators towards one autonomous artist.

Thus the second options entails that anyone can kickstart a generator at any point in time, making it "sentient". (ht @nieldlr for that terminology). Thus: multiple generators will co-exist concurrently, with multiple auctions happening simultaneously. Each generator will have its own 24 hour lifecycle.

To kickstart a generator, one has to stake soul tokens to a specific generator's curved bond. The ETH paid towards a specific generator's art goes to towards minting new SOUL tokens, which is then deposited into that specific generator's curved bond. Thus, it possible to essentially earn more SOUL tokens by participating in the game of curating good generators.

Here's an example of staking:

ETH <-> SOUL (on a curved bond).
SOUL <-> [generator] (on a curved bond).

ETH coming from artwork sold, buys SOUL tokens and deposits the SOUL tokens into that generator's curved bond. New generator tokens are NOT minted when the new SOUL tokens are deposited into the generator's bond.

The success of a generator is thus also contingent on the generator creator adding the ability to view the artwork viewer to a front-end. If they don't, then the generator won't be successful. This then also does not block the autonomous artist in general.

The downside of this implementation is it complexity, both in terms of smart contract designs (likely have to include ERC20/777 Bancor for generator curved bonds) & user experience. It will also dilute the initial value of this experiment [many more art pieces and another additional staking game].

This latter implementation thus solves the issues:

1. Incentive to stake towards generator hashes.
2. Staking to generator hashes will be contingent to whomever wants to play the game of curating generators.
3. One doesn't have to update the front-end every single time a new generator is chosen. It's not time-dependent. It just has to happen eventually. Third-party viewers can also choose to do this themselves, rather than going through a specific website.

Other options?

Subsequent forks of artonomous can become more complex and could even allow people to fork into its children by burning soul tokens across to the new artists (eg: https://medium.com/@simondlr/burning-bridges-to-greener-grass-incentivizing-tokenized-forking-393c69dfecab).

Considerations

I feel it's important to design this in such a way that there's no magic numbers involved: eg choosing a hardcoded fee or choosing a hardcoded percentage threshold. These are unknown at this stage, so would rather opt for some more continuous, market-based options.

If the autonomous artist works, we'll see people forking this anyway and applying many more generators, so might as well aim to keep the generator network effect under one engine.

Addendum

A second order benefit for multiple generators is that because a specific generator isn't required for the lifeblood of the whole autonomous artist, one can also experiment with allowing the generator creators to earn from a successful generator. In other words, each generator is dependent on it also setting a beneficiary and a fee.

An artwork would thus be combined of 4 components: [blockhash, generator_hash, generator_beneficiary, generator_percentage_fee]

Hey all,

I think it would be awesome to get a team together to hack on Artonomous at EthBerlin.

If anyone else is interested, drop a message below and we can use this issue to coordinate!

@okwme added an upgradabale metadata contract.

This is not short-term a priority, but it might be interesting to consider URIs for the metadata to be content-addressable, rather than a standard URL.

I'm not sure what ERC721s utilise content-addressed URIs for metadata. But I was thinking of doing something like pointing it to an IPFS gateway and having the metadata be pinned with a schema.org object.

In order to give the autonomous artist life, benefactors can purchase soul tokens based on a curved bond. https://medium.com/@simondlr/tokens-2-0-curved-token-bonding-in-curation-markets-1764a2e0bee5.

UPDATED & EDITED: 30 June 2018

• You can buy SOUL with ETH on a curved bond.
• Any art sold by by a specific generator gets deposited into the communal pool, buys SOUL and stakes it on the generator's own curved bond.
• The entry curve should be logarithmic.
• The generator curves should logarithmic.
• Use BANCOR as formula needs to adjust purely on the pool reserves.

ORIGINAL POST

• The soul tokens serve as a claim on the bonded ETH to keep the artonomous alive.
• Any art sold through the auction contract gets deposited into the bond.
• The entry curved should be an exponential curve.
• The exit curve is percentage-based. It allows a claim on all outstanding ETH in the bond proportional to the amount you are removing from supply.
• The soul tokens are used to stake on the hash of the software currently generating new art.

This is only relevant for shifting & multiple generators since you would be able to separately buy SOUL and not immediately stake a generator.

Each Art piece auctioned by Artonmous contains two core components that define it's unique identifier:

• the hash used to generate its art.
• the blockhash at the start of the auction.

Adding an issue related to the review on PR #15.

Art piece currently uses block.number. It should use blockhash.

As per documentation recommandations

Both the timestamp and the block hash can be influenced by miners to some degree. Bad actors in the mining community can for example run a casino payout function on a chosen hash and just retry a different hash if they did not receive any money.

Wouldn't it be safer to use blocks number as unit of time instead of the I.S ? e.g : example here

I think this is potentially where we can get some help from token engineering simulations.

For each generator, it donates some SOUL tokens that is staked to that generator to whomever starts each auction.

The goal of this is two-fold:

• Get people to start auctions (same as birthing fee for cryptokitties).
• Add some friction to kickstarting generators and keeping them alive. I think the overall value proposition of artonomous increases if generators can effectively "die" if they are not popular (the art they are generating is not that great). This latter component can be so extreme that it essentially limits the amount of generators quite a lot. eg, the long tail of generators won't really survive. But it should probably find some middle ground. What portion to donate each time is hard to determine. Can be a fixed percentage, or and adjust percentage. What that is, is still hard to figure out.

Where can I see the artwork that has been generated and participate in an auction?

Currently ArtonomousArtPieceToken depends on DNS for the metadata uri , which imo is at odds with the notion of being "self-sustaining", since DNS depends on someone maintaining backend infrastructure and creates the possibility of metadata being mutated after a token has been minted.

An alternative would be to store metadata in IPFS and use an ipfs uri, i.e. dweb:/ipfs/${hash}. Doing this would add overhead to piece creation but provides stronger guarantees around the decentralized nature of artonomous.

Would love to hear your guys thoughts!

Using this issue for the hardcoded_generator MVP.

The art generator that uses the blockhashes from the art auction generates art based on a hash pointing to a set of software used to generate the art.

The initial art generator will be: https://mattdesl.svbtle.com/generative-art-with-nodejs-and-canvas.

The hash is thus: 55f74ddc033dc34ca3b11ece54e6e569c24ea7da.

The artonomous soul tokens generated by the curved bond is used to stake towards any hash. The highest ranked hash is regarded as the current art generator.

Old artworks won't change. New artworks will be generated based on the new chosen hash.

This came up as we discussed the project at @BlockScience.

Allowing an indefinite number of generators to be active at the same time would make it very cheap to create new artwork under the artonomous "brand", which could open the doors to spammers and art forgers.

We do not need to design the solution now, but at this stage we view resolving incentives to spam the system and/or forge art as a system requirement, and would like to know everyone's thoughts on this.

Hey all.

After chatting to various folks & thinking some more, I want to put forth a re-design and re-imagining of Artonomous that fulfils part of its original goals, makes things simpler, but still maintains its interesting approach: an autonomous artist selling generative art, and using the market to curate & find good generative art. The better job it does at finding/minting new generative work, the more successful it is.

It is made simpler by reducing complexity, removing complex auctions & the reliance on many magic numbers, and thus reduces code required to create a new MVP. There's no auctions & also no generator curation. There's no SOUL anymore. However, the market will still curate the best artworks.

Reasons for the re-design was to reduce complexity but also combine new thinking around auctioning/minting.

Here's how it works:

There's only one generator (a generative art algorithm using input to create an artwork).

All artworks are minted on a bonded curve, with ETH used going into the reserve. This means that anyone can mint a new artwork with a new input they choose for the generator at the current hardcoded price as long as no art pieces are being decommissioned. If an artwork is minted, the next artwork will be more expensive to mint if the supply of artworks is not reduced.

An art owner can choose to decommission ("burn") their artwork in exchange for ETH in the reserve (at that current price point). When it is put up to be decommissioned, it is then put up for auction at the current price (in the curve) for a week. If no one buys it from that owner, then the artwork is decommissioned (burned), and the owner receives ETH back at that current price. This then lowers the price to mint a new artwork (and subsequently the minimum value of all artwork in circulation). As originally stated, a new participant can only mint their new artwork if there's no artworks that are in the queue to be decommissioned.

Thus: if someone wants to buy a new artwork with new generative input, they can do so, but only when they believe its value would basically be more than the current minimum price. Thus: over time, poorer quality artwork would be decommissioned (because no one wants it and those holders get their ETH back), and only the highest quality artwork would remain. This is because those holding the artwork can choose to keep holding it [because they like it], OR decommission their artwork at any time.

At any time, current holders of artonomous works can choose to sell at whatever price they want to.

This is thus substantially simpler:

• No complicated auctions.
• Less magic/made-up numbers (like how many artworks to mint over a set period).
• No need to curate explicitly [market does it].
• No separate token.
• The curation space is still incredibly broad. Instead of changing the generator to mint new and interesting artworks, the search space is any inputs. These inputs can be searched & discovered by anyone running the generator themselves. They have to pick which ones they like. If they find one, they can go mint it.
• It adds a mechanism for managing scarcity by adding an incentive to decommission artworks if no one wants it anymore.

The trade-offs are:

• No options currently to change or swap the generator. This could be implemented, but it's not necessary atm.

Thanks to Billy Rennekamp & Niran Babalola for sparking some thoughts around this.

PS: Thinking of forking and modifying https://www.larvalabs.com/autoglyphs. Massive contribution to this space! :)

• Preferably in Redux.
• Should be responsive and work in mobile browsers such as Status or Toshi.
• Work completely client-side. No reliance on other components.

The 'Art Auction' implements the logic used to start an auction for a generator. Once a generator has SOUL tokens stake to it, it can start a daily art auction.

EDITED & Up to date on 30 June 2018:

• A new auction can be started by anyone for any generator when it has SOUL tokens staked to it.
• A generator rewards a participant for kickstarting an auction every time with a portion of its SOUL tokens [portion tbd].
• A new auction can only be started after 24 hours and when the previous art has been claimed/bought.
• The Art Auction initiates a linear decaying price function towards zero based on a moving average of 7 (tbd) auctions. It increases by maximum by 100% if all previous 7 (tbd) auctions were sold immediately when it opened for sale.
• The time towards zero is 24 hours.
• If the previous auction ended at zero, anyone claim the artwork.
• A new auction can't be started unless the previous art piece has been claimed/bought. So if no one bought it after 24 hours, it can go on indefinitely until it's bought/claimed.
• The blockhash used in the art generation is determined at the start of auction.
• Once claimed, the an ERC721 version of the art that is created.
• The ETH paid towards buying/claiming the art goes into the curved bond pool whereupon it buys SOUL tokens that become staked to the generator's curved bond (it does NOT buy extra generator tokens).

ORIGINAL POST:

• After a cycle of 24 hours, a new auction can be started by anyone, after which a new auction can only happen after 24 hours.
• The Art Auction initiates a linear decaying price function towards zero based on the previous sale * 5%.
• The time towards zero is 24 hours.
• If the previous auction ended at zero, anyone pay anything to claim the artwork.
• It can be instantly claimed for any price above the previous art auction.
• A new auction can't be started unless the previous art piece has been claimed/bought. So if no one bought it after 24 hours, it can go on indefinitely until it's bought/claimed.
• The blockhash used in the art generation is determined at the start of auction.
• Once claimed, the an ERC721 version of the art is created.
• The ETH paid towards buying/claiming the art goes into the curved bond pool.

I want to discuss the option of dropping multiple generators for the MVP of Artonomous and just keeping/choosing one hardcoded generator with the option off off-boarding and forking into a multiple generators when the time comes.

The MVP version of Artonomous would be:

• One hardcoded generator [we can have a community voting/choosing system through issues on github].
• One curved bond: ETH <-> SOUL. Art from ETH gets deposited into pool.
• Daily auction.
• No additional staking.

This is quicker to implement, and quicker to test. Less front-end coding, and less UX issues to reason about. It is also much simpler to explain.

Once the multiple generators version goes live, the MVP of Artonomous can be restarted on it. If it's more beneficial and rewarding for the MVP of Artonomous to move its primary generator to the multiple generator artonomous it will slowly do so.

Because we are doing all of this in our spare time, I want to be very cognizant of scope creep.

The trade-off is potentially losing out on a larger network effect. But I think if multiple generators will be successful, then it will happen regardless at some point into the future.

Thoughts?

Artonomous is completely client-side and can live completely decentralized.

An ENS name for it can be utilised along with deploying to IPFS or Swarm in order to serve it.

I noticed the 721 implementation that tokenURI was being used to store the generator hash. I'd suggest the hash be stored in a separate mapping and the tokenURI be made to return a URI that contains all the metadata according to ERC721 spec. I've made an example where that part of the contract can be upgradeable if you think it's useful to use:
https://github.com/okwme/new-models-contracts/blob/master/contracts/Patches.sol
https://github.com/okwme/new-models-contracts/blob/master/contracts/Metadata.sol
tokenURI is delegated to another contract which returns a URI + the tokenId. I have a feeling the tokenURI standard may change in the future so having it upgradeable might be good too.

When new artworks are created with different generators, the front-end should be able to utilise a middleware to display them appropriately without having to drastically alter it every time it changes.