assetStore - a multi token standard about rchip-proposals HOT 6 OPEN

@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:

• How and why RChain should use Agoric’s NFT design

@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

from rchip-proposals.

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:

• Demo: create a token and add it to the AMM / Swap · Issue #616 · Agoric/documentation

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

• Agoric DEX tools: ERTP, Zoe, ... · Issue #4 · rchain-community/js2rho

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?

from rchip-proposals.

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?

from rchip-proposals.

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.

from rchip-proposals.

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.

from rchip-proposals.

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

from rchip-proposals.