CIP: Alpha spec

[odyslam]

Overall Architecture

Front-end interaction with the smart contracts

• Parcel metadata from metadata API
• Chain historical data from The Graph
• Read live data or issue transactions using Infura/Alchemy

While parcel metadata will live in a decentralized medium (Arweave), it's faster for the dashboard to pull data from an API endpoint. The API is not meant as the source of truth, but rather a faster alternative to the decentralized medium.

API

It's very easy to create a simple API using cloudflare workers. Use KV store for state storage (e.g available parcels).

Smart Contract

The smart contracts will cover 2 main groups of activities:

• DAO <--> Parcel interaction
• User <--> Parcel interaction

Actors:

• DAO: multi-sig account
• User: EOA or contract account
• Parcel: smart contract

User Stories

• As a user, I must pay an X amount in taxes every year, else my land get forfeited by the DAO
• As a user, I can lease a parcel in an Auction[1]
• As a user, I can release the lease of my parcel. I have an Y amount of days as "grace period" before the parcel is up for Auction[2].
• As a user, I can sell my parcel to another user[3]
• As a user, I can exchange my old parcel token for a new one, whenever the smart contracts are upgraded
• As a DAO, I can revoke a parcel from a user when I deem it necessary[4]

Open Questions

1. A second-price auction will probably be used, as it is generally deemed the best in game theory. More research is required to nail down its mechanism design it. We can also follow the OpenSea paradigm and its options.
2. The same type of auction as in [1]
3. The user should be able to either sell at a fixed price or have an auction as in [1].
4. This requires discussion and careful mechanism design so that everyone's incentives are aligned. It could easily dissolve to the tyranny of the masses.

Mechanism Design

At this point, we know that the user is in essence buying a lease for the land, rather than the land itself. The ultimate owner is the DAO. Due to Wyoming's law and the DAO being an LLC, the ultimate decision-maker will be the smart contract themselves. The judge of this will be the Wyoming courts.

User <--> Smart Contract <--> DAO

If at some point the user or the DAO feels that the other party is not honoring the smart contracts, it can use the Wyoming courts to settle the claim. The courts are the "meatspace" definitive application of the smart contract rules, as the smart contracts are the "definitive application of their rules in the "metaverse".

[vrohlfs]

Taking the leap of faith here @odyslam and will try to provide some insights, although some of these might have already been captured in cityDAO's notion page (I don't have access).

Project Structure :

• Small suggestion to have the project board live in the parent CityDAO (org) page, and label all the repos (3 thus far) there. This could give us better visibility and allow us to be more efficient in our product calls and onboarding additional repos. Example: https://github.com/orgs/unicef/projects/7
• We could leverage the https://github.com/citydaoproject/whitepaper repo for overall documentation. Thoughts?

User Stories:

• I really like what we have going for the user. It might be helpful for the devs to do a few user flows/journeys. I can definitely help here if that's something valuable.

• Should we split our stories more clearly between User and DAO? That can help us to be more explicit, specially for reqs like this "As a DAO, I can revoke a parcel from a user when I deem it necessary[4] " -> We can clearly define all reqs that fall under the "deem it necessary" category.