Open Simple Token

UXComposer BrandedToken+Gateway


When user actions comprise a complex set of actions across different contracts we can combine these different transactions to different contracts into a streamlined user-experience by using a “composer” contract which is specific to a common user action (think of it as a macro for smart contracts).

By using such a helper contract that acts to represent the user, we can reduce the number user signatures required for complex actions (of course the trust factor now moves to the deployment of an honest helper contract if this is done on behalf of the user).

A first draft of a specific macro for the combination of a user requesting to stake a value token (VT) (OST) for minting a Branded Token (BT) and then once minted, moving the BT into a gateway contract to move the tokens onto a sidechain/metablockchain.



Thank You Ben for sharing.
1 question:
Does stake and mint of OSTPrime needs UX Composer contract?

1 Like


Good question. First observation is that there is only a gateway contract (no BrandedToken contract) mapping (OST on Ethereum mainnet) -> (OST’ on sidechain). So it would just take two signatures from the user without the obvious need for a composer contract;

  1. OST.approve(gateway, amount)
  2. gateway.stake(amount, ..., hashlock)

However, the difference here is now that the hashlock would have to be given to the user (assuming the user is not his own facilitator). I suggest we first go without a composer contract for OST and stay with minimal scope. We can definitely evaluate this further.

1 Like


Nice OIP. The motivation and logic seems clear.

One question, though. You write the following:

Additional requirements

Composer must also support

  • transferVT , approveVT by onlyOwner
  • transferVBT , approveVBT by onlyOwner

Does this mean that the staker (owner of the UXC) must make potentially multiple transactions to transfer and approve? The UXC can not do these things autonomously?

Or asked in a different way: how will these four functions be used?

1 Like


these functions serve for when the UXC (as staker in BT contract, or as staker in gateway) gets refunded (by either rejectStakeRequest, or on a gateway.revertStake); or in some other way it gets a token balance; then the owner can control the funds on UXC balance.

It is probably worthwhile to have a more general transfer(eip20token _eip20token, address _to, uint256 _amount) over narrowing it to transferVT and transferVBT

1 Like


We must add to the specification that the UXC must have methods to call

  1. fn revertStake(...) onlyOwner { gateway.revertStake(...); }

@hackmyway are there other gateway methods that I forgot which the UXC must expose (ie. that are restricted to staker on the gateway contract)?



It would help if the OIP would list specific use-cases in the spec, I think.



@martin Thank you for your feedback. When you say specific use cases you mean elaborate specific methods transferVT, approveVT , transferVBT , approveVBT more in the OIP. correct?



Just skimmed through Gateway contract. stake and revertStake are the only two methods restricted to staker.
Confirmed with Gateway team also.
Will update in OIP too.

1 Like


Yeah. If I didn’t miss that part, it just says that these functions are required, but not what for.

1 Like


no, in good tradition it is left as an exercise to the reader :sweat_smile:. It definitely is good to expand the OIP (and others are work in progress too)