TDP:
  Title: TokeSocial Governence Proposal
  Author: Dan Kelly ([email protected])
  Status: Draft
  Type: Standards
  Created: 2018-03-31

TokeSocial Governence Proposal

This document is submitted for thoughtful consideration and discussion. All feedback will be taken into consideration for the process of formalizing these ideas into a proper proposal.

Abstract

TokeSocial requires a governence plan which fosters a community effort and all contributors are treated equally.

Core Goals

Given the minimal amount of start-up capital and uncertainty regarding the financial goals of the project, it would be prudent to avoid paying out of pocket for structure and licenses that we may not end up needing in the short term.

Specification

TokeSocial is aiming to be a community-based organization which we can all contribute to and benefit from. Governence shall be a community effort. We also propose that TokeSocial voter tokes are created simply to represent voting rights.

Tokens

It is submitted that we assign zero value to all holdings regarding the district, as to avoid any tokens we distribute becoming securities in the eyes of the law. Eight tokens will be created. One token shall be distributed to each land staker per land and represent their voting share in TokeSocial. Tokens may be minted via voted consensus to reward key staff brought into the project in the future.

Why?

Filing with the SEC would be a requirement for profit-sharing, as would setting up a legal holding to manage profits. Those things cost money and the ROI is unknown.

Voting

• Each token will carry a voting weight equal to 100% / (total active shares).
• Voting concensus is defined as 67% of all voting contributors, or greater than 50% of all voters total.
• Voting on a particular proposal shall last no longer than 7 days.
• One person's individual voting weight caps at 50% of the total vote to avoid a supermajority.

When is voting required

Everything requires a proposal and vote in order to move forward. In order to keep the project from becoming stale, district leadership suggests that one of the first proposals "fix" this issue and assign some more reasonable limitations and expectations around what shall be required to vote upon.

Future

Any and all profits and/or contributions or investments will be deposited directly into a common fund for the district arbitrated by leadership. If and when this fund reaches a value that would allow for a formal filing as an organized entity, a proposal and vote will be launched. This vote must resolve unanimously in favor of the decision to move forward. If the vote is greater than 51% in favor, those who vote nay must allow themselves to be bought out by any willing party in favor of filing. If the vote is less than 51% in favor, the motion will fail and a revote may be called by leadership no shorter than two months later.

Work in progress draft

  TDP: 0030
  Title: TokeSocial Initial Launch, MVP Proposal
  Author: Dan Kelly ([email protected])
  Status: Draft
  Type: Process
  Created: 2018-02-26

Abstract

A minimum viable product description utilizing the planned features of the initial Decentraland "Iron Age" launch. Although the goal is to stick to the plans as closely as possible, sometimes there are hickups, the plans and guidelines outlined here are an aspirational vision and should not be considered a promise.

Copyright/public domain

Open Publication License.

Specification

• Initial supported features / restrictions - static 3D content, no animations or interactive properties.
• Start up facilities
  • Lounge style area for socialization
  • Speakers, events
  • Cannabis inspired art (will require some approval)
  • Comming soon sneak peak at cannabis themed arcade games
• Proposed initial building layout
• Marketing, social media
  • Attracting users
• Partnerships
  • Advertising
  • Image and video rights
• Post startup
  • Associated revenue projects (additional tokens - ERC, NFT)
• District Leader definition
• Assignment of initial team, 3D modeling, technical lead, public relations and funding requests
  • Membership token requiring valuation first?
• LAND ownership (multisig wallet, district leader and the Decentraland team)
• Communication
• Governence
  • To use TDP0010 until TDP0011 is use in replacement
• Milestones
  1. LAND multisig wallet
  2. Final district approval by Decentraland, LAND acquisition
  3. LAND deployment
  4. Permanent governence model definition and deployment
  5. Start planning for the next phase of available features!
     • Video playback
     • Animation
     • Arcade games

Motivation

The motivation is critical for TDP that wants to implement within TokeSocial. It should clearly explain why the existing specification is inadequate to address the problem that the TDP solves. TDP submissions without sufficient motivation may be rejected outright.

Rationale

The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported elsewhere.

• The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.

Backwards Compatibility

All TDP that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The TDP must explain how the author proposes to deal with these incompatibilities. TDP submissions without a sufficient backwards compatibility treatise may be rejected outright.

Reference Implementation

The reference implementation must be completed before any TDP is given status "Final", but it need not be completed before the TDP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.

• The final implementation must include test code and documentation appropriate for the Decentraland protocol and TokeSocial policies.

How to define and propose new ideas, features, processes and policies to the TokeSocial district.

  TDP: 0000
  Title: TokeSocial District Proposal Format
  Author: Dan Kelly ([email protected])
  Status: Active
  Type: Process
  Created: 2018-02-26

Table of Contents

1. TDP: TokeSocial District Proposal Format
   1. What is a TDP?
   2. TDP Types
   3. TDP Workflow
      1. TokeSocial Leadership
      2. Submitting a Proposal
      3. What belongs in a successful TDP?
      4. Consensus
   4. TDP Formats and Templates
      1. TDP Header Preamble
      2. Auxiliary Files
   5. Transferring TDP Ownership
   6. TDP Editors
      1. TDP Editor Responsibilities & Workflow
2. History
3. Changelog

TDP: TokeSocial District Proposal Format

This document describes the mechanism for proposing policy for discussing TokeSocial's ecosystem of activities and features.

What is a TDP?

TDP stands for TokeSocial District Proposal Format. A TDP is a design document providing information to the TokeSocial community, or describing a new activity or feature for TokeSocial district or ecosystem, or its processes, environment, or policy. The TDP should provide a concise technical specification of a proposal and a rationale for it.

We intend TDP to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions. The TDP author is responsible for building consensus within the community and documenting dissenting opinions.

Because the TDP are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

TDP Types

There are three kinds of TDP:

• An Informational TDP describes a TokeSocial design feature, challenge, issue or event; but it does not propose a new change. These can be useful to describe and log an historical event or decision taken at some point, or call for solutions for a given problem to the community. Information TDPs are often the precursor to a successful process, standard or business track TDP.
• A Process TDP describes a process surrounding TokeSocial, or proposes a change to (or an event in) a process. They may propose an implementation, procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in TokeSocial development. Any meta-TDP is also considered a Process TDP.
• A Standard Track TDP describes any new feature to TokeSocial. This is useful for proposals who's effort is to make TokeSocial more enjoyable and attractive to newcomers as well as retain loyal visitors. This could include new activities, environment or design changes to the vr modeling, websites, marketing, etc. he standard track specifically excludes any feature which the primary focus is revenue based. These prosals should be filled under the business track.
• A Business Track TDP describes any new feature or change who's goal is to bring revenue into TokeSocial. This is useful for proposals who's effort is to make some revenue for the TokeSocial investors in a fun manner.

TDP Workflow

TokeSocial Leadership

The TokeSocial district leaders are currently the team charged with the task of building the infrastructure and procedures to build the initial TokeSocial experience. Most initial TDP are authored by them, and they are the main promoters of the process and the district.

Submitting a Proposal

The TDP process begins with a new idea for TokeSocial. Each potential TDP must have a champion -- someone who writes the TDP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The TDP champion (a.k.a. Author) should first attempt to ascertain whether the idea is TDP-able. Posting an issue to the GitHub TDP repository is the best way to go about this.

Once the champion has asked the TokeSocial community as to whether an idea has any chance of acceptance, a draft TDP should be presented as a pull request to that repository. This gives the author a chance to flesh out the draft TDP to make it properly formatted, of high quality, and to address additional concerns about the proposal. Following a discussion, mention one of the TDP editors to review the TDP draft and accept the pull request. This draft must be written in TDP style as described below, else it will be rejected without further regard until proper formatting rules are followed.

TDP authors are responsible for collecting community feedback on both the initial idea and the TDP before submitting it for review. However, wherever possible, long open-ended discussions on chat or public forums should be avoided. Strategies to keep the discussions efficient include: setting up a channel within the chat server for the topic, having the TDP author accept private comments in the early design phases, setting up a wiki page, etc. TDP authors should use their discretion here.

It is highly recommended that a single TDP contain a single key proposal or new idea. The more focused the TDP, the more successful it tends to be. If in doubt, split your TDP into several well-focused ones.

The TDP editors assign TDP numbers and change their status. Please send all TDP-related email to the TDP editor, which is listed under TDP Editors below. Also see TDP Editor Responsibilities & Workflow. The TDP editor reserves the right to reject TDP proposals if they appear too unfocused or too broad.

Authors MUST NOT self assign TDP numbers, but should use an alias such as "dsd-newavatars" which includes the TDP subject.

If the TDP editor approves, he will assign the TDP a number, label it as the appropriate TDP Type, give it status "Draft", and merge it to the main branch of the TDP git repository. The TDP editor will not unreasonably deny a TDP. Reasons for denying TDP status include duplication of effort, disregard for formatting rules, being too unfocused or too broad, being technically unsound, not providing proper motivation or addressing backwards compatibility, or contrarial to the TokeSocial philosophy. For a TDP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

The TDP author may update the Draft as necessary in the git repository. Updates to drafts may also be submitted by the author as pull requests.

Standards Track TDP (and Business Track TDP when appropriate) consist of two parts, a design document and a reference implementation. The TDP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the TDP. Standards Track TDP must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.

Once a TDP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the community, the status will be changed to "Final".

A TDP can also be assigned status "Deferred". The TDP author or editor can assign the TDP this status when no progress is being made on the TDP. Once a TDP is deferred, the TDP editor can re-assign it to draft status.

A TDP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact.

TDP can also be superseded by a different TDP, rendering the original obsolete. This is intended for Informational TDP, where version 2 of an API can replace version 1.

Some Informational and Process TDP may also have a status of "Active" if they are never meant to be completed. E.g. TDP 0000 (this TDP).

What belongs in a successful TDP?

Each TDP should have the following parts:

• Preamble -- RFC 822 style headers containing meta-data about the TDP, including the TDP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
• Abstract -- a short (~200 word) description of the technical issue being addressed.
• Copyright/public domain -- Each TDP must either be explicitly labelled as placed in the public domain (see this TDP as an example) or licensed under the Open Publication License.
• Specification -- The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current TokeSocial features.
• Motivation -- The motivation is critical for TDP that wants to implement within TokeSocial. It should clearly explain why the existing specification is inadequate to address the problem that the TDP solves. TDP submissions without sufficient motivation may be rejected outright.
• Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported elsewhere.
  • The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
• Backwards Compatibility -- All TDP that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The TDP must explain how the author proposes to deal with these incompatibilities. TDP submissions without a sufficient backwards compatibility treatise may be rejected outright.
• Reference Implementation -- The reference implementation must be completed before any TDP is given status "Final", but it need not be completed before the TDP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code.
  • The final implementation must include test code and documentation appropriate for the Decentraland protocol and TokeSocial policies.

Consensus

The term "consensus" is used loosely in this document, in most cases refers to general consensus and simply "getting a feel for the crowd". When the term "consensus" is used in respect with final voting of proposals, it is defined as 67% of responding registered contributors within 7 days of starting the vote or 67% of all registered contributing members at anytime.

TDP Formats and Templates

TDP must be written markdown format. There is an example TDP which can be copied from tdp/example.md.

TDP Header Preamble

Each TDP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "#" are optional and are described below. All other headers are required.

  TDP: <TDP number>
  Title: <TDP title>
  Author: <list of authors names and optionally, email addresses>
# Discussions-To: <email address>
  Status: <Draft | Active | Accepted | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  Type: <Standards Track | Informational | Process>
  Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
# Replaces: <TDP number>
# Superseded-By: <TDP number>

The Author header lists the names, and email addresses of all the authors/owners of the TDP. The format of the Author header value must be

Author: Random A. User <[email protected]>

If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.

Author: Random A. User <[email protected]>
Author: Random B. User <[email protected]>

Note: The Resolution header is required for Standards Track TDP only. It contains a URL that should point to an email message or other web resource where the pronouncement about the TDP is made.

While a TDP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate a chatroom, forum thread, or URL where the TDP is being discussed. No Discussions-To header is necessary if the TDP is being discussed privately with the author, or on Decentraland's RocketChat chat service.

The Type header specifies the type of TDP: Informational, Standards, Process, or Business track.

The Created header records the date that the TDP was assigned a number, while Post-History is used to record the dates of when new versions of the TDP are posted to the TokeSocial District Proposal GitHub issue tracker. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.

TDP may have a Requires header, indicating the TDP numbers that this TDP depends on.

TDP may also have a Superseded-By header indicating that a TDP has been rendered obsolete by a later document; the value is the number of the TDP that replaces the current document. The newer TDP must have a Replaces header containing the number of the replaced TDP.

Auxiliary Files

TDP may include auxiliary files such as diagrams. Image files should be included in a subdirectory for that TDP. Auxiliary files must be named TDP-XXXX-Y.ext, where "XXXX" is the TDP number, "Y" is a serial number (starting at 1), and "ext" is replaced by the actual file extension (e.g. "png").

Transferring TDP Ownership

It occasionally becomes necessary to transfer ownership of TDP to a new champion. In general, we'd like to retain the original author as a co-author of the transferred TDP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the TDP process, or has fallen off the face of the 'net' (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the TDP. We try to build consensus around a TDP, but if that's not possible, you can always submit a competing TDP.

If you are interested in assuming ownership of a TDP, send a message asking to take over, addressed to both the original author and the TDP editor. If the original author doesn't respond to email in a timely manner, the TDP editor will make a unilateral decision (it's not like such decisions can't be reversed :).

TDP Editors

The current TDP editor is Daniel Kelly who can be contacted at
[email protected]

TDP Editor Responsibilities & Workflow

The TDP editor watches the TDP repository on GitHub. All TDP-related correspondence should be sent (or CC'd) to the [email protected].

For each new TDP that comes in an editor does the following:

• Read the TDP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to be accepted.
• The title should accurately describe the content.
• Edit the TDP for language (spelling, grammar, sentence structure, etc.), markup (visual formatting), and code style.

If the TDP isn't ready, the editor will send it back to the author for revision, with specific instructions.

Once the TDP is ready for the repository it should be submitted as a "pull request" to the TokeSocial Proposals repository on GitHub where it may get further feedback.

The TDP editor will:

• Assign a TDP number (the next available number, or maybe some number grouped together with similar TDP, but sometimes a special/joke number, like 1337) in the pull request comments.
• Merge the pull request when the author is ready (allowing some time for further peer review).
• List the TDP in README
• Send email back to the TDP author with next steps.

The TDP editors are intended to fulfill administrative and editorial responsibilities. The TDP editors monitor TDP changes, and correct any structure, grammar, spelling, or markup mistakes we see.

History

This document is heavily based on Decentraland's DSP format.

• DSP: Decentraland Specifications Proposal Format

Changelog

• Febuary 26th, 2018: Initial document
• Febuary 27th, 2018: Updated grammar, added clarification to the term "consensus"

I propose using GitHub comments as a temporary solution for members to discuss and cast votes vocally.

  TDP: 0010
  Title: Temporary Voting Mechanism for TokeSocial District Proposals
  Author: Dan Kelly ([email protected])
  Status: Draft
  Type: Process
  Created: 2018-02-26

Abstract

A temporary voting mechanism for contributors to vote on various proposals to be implemented within the TokeSocial district of Decentraland. It should be easy to tally and record votes.

Copyright/public domain

Open Publication License.

Specification

Utilize GitHub issue comments to show support for TDPs. Contributors should simply comment on the issues to show support or non-support of various proposals.

• All users must use an existing or create a new GitHub account to comment.
• In the case of non-support, describe why you do not support and recommend amendments.
• Approval status should be based on the final proposal document. It is important to get unofficial consensus before asking for a vote and wasting members' time.
• GitHub comment edit history is preserved, TDP editor should send screenshots to a timestamping service such as https://opentimestamps.org/

This will be the last proposal to go through with an official consensus vote, although plenty of time will be given to allow contributors to voice their opinions.

Motivation

TokeSocial is building a community project and as such there must be a mechanism to fairly acquire consensus among contributors. There is currently no specification for a voting mechanism in TokeSocial and this is meant as a temporary solution. It should be adequate to get the project off the ground.

Rationale

The goal is to get an initial MVP running as soon as possible. This temporary solution requires very little work and can be deployed immediately until decentralized, immutable voting mechanisms are available.

TODO: Update with evidence of voiced consensus

Draft proposal for membership tokenization

  TDP: 0020
  Title: TokeSocial Membership Share Representation
  Author: Dan Kelly ([email protected])
  Status: Draft
  Type: Standards
  Created: 2018-02-27

Table of Contents

1. Abstract
2. Copyright/public domain
3. Specification
   1. ERC20 Token
      1. Initial Distribution
         1. Contributor fund
         2. Startup fund
         3. District share
            1. Allocation of district fund
         4. Founding leadership fund
      2. Transferability
      3. Loss of wallet private keys and theft
   2. Voting
      1. Protecting against 51% attacks
   3. Mitigation against 51% attack
4. Motivation
5. Rationale
   1. Other considerations
      1. Distribute land to contributors
      2. Distribute 100% membership tokens to contributors
      3. Distribute some utility token
6. Reference Implementation

Abstract

TokeSocial contributions should be represented via a "membership" token (TOKE) in order to provide incentive to labour contributors and expenses.

Copyright/public domain

Open Publication License.

Specification

TokeSocial shall use an ERC20 token to represent contributors share in the project. This will represent the weight of contributors' votes and any revenues that may develop in the future.

ERC20 Token

ERC20 is an existing token standard easily adopted to provide a decentralized immutable ledger of contributors. OpenZeppelin's Zeppelin-Solidity contracts provide a proven reliable and secure base. Strong precautions, exhaustive review and unit testing should take place with any changes and new features to the Zeppelin contracts.

ERC20 tokens are decentralized and immutable, like Ethereum and Bitcoin. Although ERC20 carries a lot of desired properties for this application, some properties can also be seen as a negative effect. Ultimately, knowledge and understanding are mandatory.

Initial Distribution

• Distribution is:
  • 30% to contributors
  • 30% to the startup fund
  • 20% to the district share
  • 20% to the founding leadership

Contributor fund

30% of the initially minted tokens shall be distributed proportionally to the LAND contributors based on the LAND contributed. These tokens serve as a record of share ownership of the TokeSocial project. These tokens give TDP votes more weight and may carries the value associated with.

Startup fund

30% of the minted tokens shall be used by the district to reward contributors for their efforts as well as onboard new members in exchange for their services during the district's startup.

• TokeSocial shall always strive to in-source work to existing contributors first
• Distribution of these token shall be determined by vote of the existing contributors.
• These tokens carry voting rights.
• The startup fund tokens shall only be used based on approval of proposals.
• This fund shall be used for startup costs until the the district can cover it's own costs.

District share

20% of the minted tokens shall be held in reserve for the district and never to be spent. The district itself cannot vote, these tokens represent the revenue share the district keeps for ongoing costs. Maintenance, upgrades, land expansion, etc. Revenues shall be spent based on consensus vote of proposals.

Founding leadership fund

20% of the minted tokens shall be locked in the vesting contract and are released after 1 year. These tokens serve as incentive to organize and plan the TokeSocial district. Writing up proposals, refining ideas, recruiting and managing project contributors, filling in the gaps, and making TocialSocial and enjoyable experience for everyone. It is up to the district leaders to get the right people togethor and have TokeSocial built and maintained.

Transferability

In order to effectively contact and build a team of dedicated project supporters, TokeSocial shall require any prospective contributor (receiver of "TOKE" tokens) to be approved by project leader(s) before they may receive membership tokens. This serves mainly as a filter to onboard valuable contributors.

Loss of wallet private keys and theft

In the event of loss of your wallet private keys, access to your membership tokens (TOKE) would be lost as well as any voting right or profit sharing. Make sure you backup your private keys safely and responsibly.

Theft of private keys is a large risk with ERC20 and crypto currencies in general. If you can, always use hardware wallets to store your membership tokens.

It is the contributors responsibility to research and understand Ethereum private key security and to take appropriate measures to secure their wallet private keys.

Voting

This membership token carries weighted voting rights on TDPs. Votes are weighted by the amount of membership tokens carried by the voter.

Mitigation against 51% attack

No single contributor may vote for more than 50% of a proposal unless there are no opposing voters. With no opposing voters this effectively enforces a minimum 2/3 supporting voters.

Profit distribution

Profit generation shall not be the short term focus of TokeSocial and for all intensive purposes does not give membership tokens (TOKE) any value.

We need to explore more what this would look like from a legal standpoint. In the case of any profit generation TokeSocial shall distribute (or reserve until the legal infrastructure is in place) them proportionally to membership token (TOKE) holders. One suggestion is to file an SEC Regulation Form D exemption. This restricts TokeSocial to less than 35 investors and requiring less than $1 million per year in investment. This may require registering TokeSocial as a corporation in Canada and possibly the United States. District Leadership will be responsible for setting up the corporation and shall be named as part of the board directors. Any associated costs shall be reimbursed via the start-up fund membership tokens.

Motivation

The district is not going to build itself. There are 11 parcels of land to build on (including additional parcel from dafky2000, district leader), they need content, the project needs marketing and people need to be rewarded for the work involved. It is not the vision of TokeSocial to have many ride on the backs of a few who are willing to do the work and make TokeSocial a success.

It is also not the vision of the project to outsource everything and give all the membership tokens away. We shall strive to in-source all work required for TokeSocial's success, giving existing contributors the opportunity to earn a determined rate for their hard work. When required, the district leader shall find someone outside of the district to do the work.

Rationale

The goals of TokeSocial shall remain in tact, it is a community based project to provide a safe place for cannabis users and supporters to gather and discuss issues and opportunities in the industry. TokeSocial requires services and resources to trade for those services to build this community and it is important that those "putting the time in" or incur additional expense are rewarded or reimbursed appropriately.

Contributors first, decentralization, and fairness are the primary motivators for the decisions in this document.

Other considerations

There are a few other options that were considered and none of them can be done fairly, some reasoning is outlined below.

Distribute land to contributors

This is extremely difficult, especially on such a small scale.

• Who gets the roadside parcels? Who gets the rear end parcels?
• Are contributors interested in selling the land, or building on it?
• Why organize a "district" at all?

Distribute 100% membership tokens to contributors

This was also considered but it has been determined:

• The district leader has no incentive to progress the project.
• There is no incentive to build TokeSocial and build the proposal as outlined.
• The opportunity existed to purchase LAND to build on in the auction.

Distribute some utility token

Decentraland has made it clear that MANA will be the in-game currency. This is also not an accurate representation of contribution or share of vested interest in TokeSocial as a community project.

We may consider utility tokens for use outside of Decentraland as an additional benefit to membership token (TOKE) holders in the future.

Reference Implementation

• TODO: Build reference membership ERC20 token code