The problem Token with Manifesto solves

Problem

Since the establishment of the ERC20 standard, token handling has become easier and a variety of tokens have been created. In addition, DeFi (Decentralized Finance) services have been enhanced.

Many projects are sincerely trying to increase the value of their tokens, but in contrast, there are more and more people who generate tokens in a messy manner or handle them fraudulently.

Recently, individuals and communities have been issuing tokens, known as Social Token, and we expect more and more tokens to be issued in the future.

Therefore, we thought it is necessary to have a tool that can increase the reliability of tokens.

Solution

So, in this hackathon, we have developed a tool that allows users to directly add a "Manifesto" to the token contract, which defines the purpose of the token issuance and operation policy.

What is unique about this is that in addition to the manifesto being tied to the token, the manifesto needs to be signed by three people. This manifesto is managed on Textile Bucket and Ceramic, and the signature on the manifesto is done by the wallet associated with IDX.

This gives the token issuer more incentive to ensure that the token is properly managed than if the token is issued freely. In addition, token holders will be able to verify the manifesto and the signatories, which will make them feel more secure in their tokens.

In addition, many services provide information on how to use the tokens on their websites, but this is a time-consuming process for individuals and communities. With "Token with Manifesto", manifesto information is managed within the token contract, making it easier to manage.

This token is an approach to increase value through Proof of Relationship, and we believe that it can be one of the new token issuing styles in the coming Social Token era.

Challenges we ran into

• We were new to DID(Decentralized Identity) used in Ceramic Network IDX. So during research and development, we survey it with such as W3C DID specification and read a lot of documents.
• Rather than simply using IPFS, we spent a lot of time figuring out how to design a seamless combination of data management and contracts tied to Identity. It took me a long time to understand the structure of Ceramic and Textile.
• The Brave browser set "cookie blocking" by default. So, when using IDX, the IDX authentication popup was displayed every time the page loaded. We have temporarily disabled "cookie blocking", but this is not a good thing for Brave browser users.
• When creating the Subgraph, it took me a while to understand how to track the ERC20 contracts generated from the Factory contract. In the end, I was able to achieve this using the Template feature.
• Deploying the frontend app to IPFS was difficult a bit. IPFS is File System and not exactly for SPA applications such as React we used in this hackathon and we got a 404 error for routing. We solved it with an online resource like following
• We could not find and so not use GUI explorer for Ceramic, IDX, or Textile. So it was difficult to debug data and flow while developing. At this time, we output a fetched data to log and checked it when it's necessary.
• Website linking with Unstoppable domains is great for human-readable IPFS websites, but currently, the Ethereum gas fee was so high and therefore meta transactions seemed stagnated. We decide to link a website to an unstoppable domain by sending transactions on our own, so we successfully did it(but its gas fee was not cheap still).