@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.
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.
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?
What should happen with any token dust?
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.
// "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?
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?
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?
Since restriction is about transfer and not holding/redeeming, should it be possible to place a restriction after lifting it?
Can an allowance be set for a spender who is restricted?
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?
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?
What, if anything, links BT and its utility representation?
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?