Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assetStore - a multi token standard #30

Open
SteveHenley opened this issue Sep 4, 2020 · 6 comments
Open

assetStore - a multi token standard #30

SteveHenley opened this issue Sep 4, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@SteveHenley
Copy link
Collaborator

Is your feature request related to a problem?

No.

Describe the solution you'd like

The RChain platform needs to develop a multi-token standard.

Describe alternatives you've considered

ERC 1155 is an example of an existing multi-token standard.

Additional context

The naming convention for the RCHIP multi-token standard presents a problem. One thought is to use the 1155 number scheme so users can quickly identify and relate to the standard. This is helpful from a marketing point of view. However, the RChain standard, once created, will be vastly different from ERC 1155. One possibility is to simply call the RChain standard "assetStore".

@SteveHenley SteveHenley added the enhancement New feature or request label Sep 4, 2020
@dckc
Copy link

dckc commented Sep 7, 2020

We have the MakeMint contract; in what way does it not suffice?

p.s. shouldn't a "no" answer to the "related problem?" question result in this proposal being summarily closed?

@zsluedem
Copy link

zsluedem commented Sep 7, 2020

Yeah. I also want to adopt something like this in the explorer.
Although we got the https://github.com/rchain/rchain/blob/dev/casper/src/main/resources/MakeMint.rho for, I think we'd better write some other contract which can store transfer on-chain.

@dckc
Copy link

dckc commented Sep 7, 2020

If a conventional explorer is a requirement, MakeMint is not enough on its own.

The explorer conventions involve having a public name (string / integer) for every account and having transactions straightforwardly indexed by those names, at least by services that index the blockchain contents.

These conventions have always baffled me. In the normal consumer economy, we don't have public names for our wallets and we don't publish a history of every dollar we spent or earned. The issuer (aka Mint) of dollars, the US Govt, is a very public entity. Banks have routing numbers and checking accounts have numbers and credit cards have numbers. But I don't have to use a bank or a credit card if I don't want to. And bank account numbers and credit card numbers are not generally published.

The MakeMint contract guarantees conservation of tokens all by itself. The other accounting systems belong in optional higher layers, in my opinion.

@dckc
Copy link

dckc commented Sep 17, 2020

Our MakeMint contract is missing recent ERTP refinements - Issuer, AmountMath, etc. in order to support non-fungible tokens etc. We should port these from https://agoric.com/documentation/ertp/guide/

And we should have rholang type signatures ... ideally including behavioral types to demonstrate security properties.
https://github.com/rchain-community/behavr
https://arxiv.org/abs/2002.08334

p.s. for some progress around July 2021, see https://github.com/rchain-community/rgov/blob/master/rholang/core/RevIssuer.rho

@dckc
Copy link

dckc commented Aug 9, 2021

@Bill-Kunj , @steverosstalbot do you expect to use https://github.com/fabcotech/rchain-token in the Eve Arnold NFT PoC? At the headline level, 226 Apr 14 Community Debrief - RChain token for NFT's etc, self sovereign id and the Covid Passport - RChain Blog suggests that you would.

I'm curious to know whether it's consistent with ERTP, i.e. with makeMint generalized with AmountMath.
I owe a review of more recent rchain-token work; my earlier review suggested that it is not compatible: fabcotech/rchain-token#2 . I sure hope that this issue gets addressed, since rchain-token is the defacto multi token standard for RChain.

This is a follow-up to my earlier suggestion:

@Bill-Kunj , unfortunately I didn't manage to include you in that discussion; perhaps I'll find a time to sync with you.

cc @fabcotech @rholang @jimscarver

@dckc
Copy link

dckc commented Feb 26, 2022

Demo: Make a token and put it on the automated market maker a la Uniswap

An ERC20 analog is pretty clearly the goal of this RCHIP. And UniSwap brought the ERC20 market to a new level. @kennyrowe and I did a demo of the Agoric platform equivalent of making an ERC-20 token and putting it on the Automated Market Maker:

Porting this (both ERTP and the AMM contract) to rholang is a straightforward, nearly mechanical bit of work if RChain adopts ERTP:

ERTP includes non-fungible tokens as well as fungible. And in a recent enhancement, it includes "semi-fungible" tokens. (details available on request).

I'm available to discuss this in my Saturday awesome-ocap office hours tomorrow at 1400Z. Anybody interested?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants