Open Simple Token

Branded Token OIP-0001


#1

With OpenST we want existing mainstream applications to be able to create their own token for their application that has a market value, without doing an ICO. To this end we propose a Branded Token (BT) which can be backed by existing value tokens.

OST is the first such an ecosystem token, but further implementations can have a basket of value tokens to back a Branded Token (to reduce volatility when assets are negatively correlated).

As a foundational rule of OpenST, any owner of a Branded Token can always redeem for the underlying value of the Branded Token (without approval of an other actor) - what you earn in the application, you own as an end-user!

To date, an application cannot run directly on Ethereum mainnet - it would congest Ethereum mainnet and further exacerbate the storage problem of Ethereum mainnet. Rather OpenST can move the application transactions to an open Ethereum side chain using a Mosaic gateway (or another layer-2 scaling solution).

However, for a Branded Token to be a utility token it needs to be only useable inside the application. And because this cannot run on Ethereum mainnet, we introduce the property “restricted”. Only the layer-2 scaling contracts on Ethereum mainnet should be restriction-lifted so users can move Branded Tokens in-/and out- of the scaling solutions where the application runs - but a secondary market of the tokens on Ethereum mainnet (outside of the application) is impossible.

Within the application, it must be possible to map blockchain user addresses to users inside the application. To this end, we define the property of being “internal”.

Starting discussion for https://github.com/OpenSTFoundation/OIPs/pull/8


#2

@ben, thanks for this proposal. Based on the latest PR, please find some questions and comments below. You may not have answers to all questions, but even knowing that/what your thinking is with respect to the answer will be very helpful.

I’ve tried to quote the proposal where I thought helpful.

General

Could you please clarify how a BT will be “designed specifically” for a mainstream application’s context?

Please clarify how a BT supports a mainstream application having its own token with a “market value”, particularly given the restrictions:

… we want the value definition of the Branded Token to be declared on Ethereum mainnet, but restrict its direct use.

The property internal for a token restricts the creation of a secondary market of the token while allowing open transactions within the context of the intended application.

I don’t understand the connection between the transaction throughput of Ethereum mainnet and (a) defining BT value and (b) restricting BT use on Ethereum mainnet. Could you please further explain?

Because Ethereum mainnet cannot support the transaction volume of any mainstream application, we want the value definition of the Branded Token to be declared on Ethereum mainnet, but restrict its direct use.

There are terms used for which I think definition would improve comprehensibility, especially if they or their use are specific to OpenST: value token, OST, Organisation, UX-composer.

Specification

Please clarify how controlling a BT via an Organisation affects the determinability of the total supply:

A Branded Token (BT) can be organised[OIP-] such that accepting a stake request to mint more Branded Tokens backed by OST can be controlled by the Organisation such that the total supply is determinable.

Please indicate which functions will be controlled by which aspects of an Organisation?

Is conversion information set upon construction? Does BT expect the value token to be EIP20 / is it hard-coded as OST? (These may be more implementation questions.)

The BT can be staked at constant conversion rate BT:OST

How will staking against a basket of value tokens be achieved?

… or can be staked against a basket of value tokens.

Should there be an explicit function for rejecting a stake request?

Are there events for successfully calling functions (e.g., requestStake, acceptStakeRequest, etc.) and, if so, what information should be included in those events, if any?

ValueBacked

What should happen with any token dust?

requestStake

Previous versions of the OpenST protocol have indicated minting for the benefit of a beneficiary, but there is no beneficiary argument in requestStake or the StakeRequest struct. Has the beneficiary concept been dropped or is it something with which the BT is not concerned?

For the sake of clarity, is it expected that only a staker will be calling requestStake?

Regarding the stakeRequestHash, this proposal appears inconsistent because it specifies calculating the hash according to EIP 712 but specifies a domain separator different from EIP 712 (assuming, as some implementations do, that the specification is prescriptive and not descriptive). Please clarify what is expected in BT—apologies if this not inconsistent and I’ve misunderstood 712.

//keccak256(
//    "EIP712Domain(address brandedTokenContract)"
//);

Regarding the stakeRequestHash, is the amount the request’s stake or mint value?

Regarding the stakeRequestHash, how is the nonce used:

  • as a unique identifier (allowing requests to come in any order);
  • as an incrementing value (requiring requests to come in a specific order; or
  • the EIP 1077 approach (ordered and out-of-order are permitted)?

Related to the nonce question above, can a staker have multiple requests that are neither accepted nor revoked?

acceptStakeRequest

Please clarify how the ownership of UX-composer impacts the BT:

… because the caller might be a UX-composer contract owned by the staker.

For the sake of clarity, who is expected to sign the stakeRequestHash?

How does acceptStakeRequest involve the staking architecture (e.g., Mosaic gateway), if at all?

redeem

Are there any architecture-related restrictions on redemption? For instance, depending on the architecture, a staker could redeem tokens minted in acceptStakeRequest before those tokens are staked for their utility representation. Is this something with which the BT should concern itself?

Should redemptions that convert to 0 value tokens be rejected?

Restricted

Since restriction is about transfer and not holding/redeeming, should it be possible to place a restriction after lifting it?

approve

Can an allowance be set for a spender who is restricted?

transferFrom

Regarding transferFrom, it looks like the spender is restriction-checked, but not the transferor. I would expect the opposite, so I don’t think I understand. Could you please clarify?

liftAllRestrictions

Please clarify why a function that lifts all restrictions and is one-time callable is recommended.

Assuming the lifting of restrictions is honored by checking a flag, is such check performed by the onlyUnrestricted modifier? Otherwise, please clarify how it would work?

Utility representation

What, if anything, links BT and its utility representation?

Implementation

Do you anticipate that the implementation of BT will be a contract that inherits the interfaces as described in this proposal or are the interfaces for representation/specification ease in this proposal and there may not be interfaces that accompany the BT contract in the relevant repository?

Do you anticipate that a BT will be agnostic as to the architecture (i.e., layer-2 scaling solution) in which it is used, or BT will be a base upon which specific BTs are built. For example, will there be an implementation of BT that is specific to the Mosaic gateway?

Which concerns raised in this proposal, if any, will not be addressed in the initial/mvp implementation?


#3

Ethereum PoW works today as a blockchain with good security properties (specifically also good liveliness properties); but it is constraint in its computational throughput. Therefore we build Mosaic, to extend Ethereum mainnet computational capacity with a layer-2 BFT Proof-of-Stake consensus engine which finalizes the history of side chains. That way we can compute in parallel across many metablockchains, leveraging the bits secured by PoW.

The BrandedToken contract defines the token on Ethereum mainnet, but given the computational constraints, and storage constraints of Ethereum mainnet, we move the execution of the application to the side chain, using a “utility representation” of the tokens on the side chain of the tokens staked on mainnet. Because the application cannot live on mainnet, we restrict the applications’ tokens on mainnet.