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

Show bonding / redelegation transactions #808

Closed
faboweb opened this issue Jun 7, 2018 · 13 comments
Closed

Show bonding / redelegation transactions #808

faboweb opened this issue Jun 7, 2018 · 13 comments
Labels
design-work-needed 🎨 issues that require design work before development split 🍌 issues that need to be split into several smaller issues with reduced scope

Comments

@faboweb
Copy link
Collaborator

faboweb commented Jun 7, 2018

UI Version: 0.6.2

Description:

The bonding / unbdonding and redelegation transactions need to be visualized. Those transactions have a period when they are running but are not in full effect. For unbonding the user needs to send another transaction that finishes the unbonding. The same goes for redelegation. The SDK team agreed, that not sending these transactions will not have a negative effect for the user. But it will not free up funds. And it is desired that redelegations are closed to clean up. So we should incentivize the user to close these redelegations.
Maybe the ending txs could be send automatically by Voyager (optin/optout by the user).

pulling in @jolesbi @nylira

@faboweb faboweb added the design-work-needed 🎨 issues that require design work before development label Jun 7, 2018
@cwgoes
Copy link

cwgoes commented Jun 8, 2018

Note that even if the ending transactions are presigned and sent automatically, the user will need to open Voyager again after the three-week period has passed; if the transactions are broadcast before they are valid they'll just fail.

@jbibla
Copy link
Collaborator

jbibla commented Jun 8, 2018

can we break down the flow for each use case?

bonding

  1. user bonds some atoms
  2. period of no effect?
  3. another bonding tx?
  4. bond finished?

unbonding

  1. user unbonds some atoms
  2. 1 month unbonding period
  3. another unbond tx?
  4. unbonding finished?

redelegation

  1. user redelegates atoms
  2. period of no effect?
  3. another redelegation tx
  4. redelegation finished?

@faboweb
Copy link
Collaborator Author

faboweb commented Jun 11, 2018

I think bonding works immediately.
The rest sounds right.

@faboweb
Copy link
Collaborator Author

faboweb commented Jun 21, 2018

Consider #355

@nylira
Copy link
Contributor

nylira commented Jun 27, 2018

This second unbonding transaction is extremely user unfriendly. Let's make it easier on the user and have Voyager automatically make the second unbonding transaction once the unbonding period is over.

That's much less work for our users. All we have to do is show pending unbonding periods on the user's transaction history.

To resolve the part about the user having to re-open voyager after 3 weeks to finish unbonding, let's consider the idea of a Voyager Daemon

voyagerd

It runs at all times on the user's computer. It can be placed in the system tray on Windows, and in the menu bar for macOS. It's main purpose is to offer hub notifications to the user. Events like:

  • user's pending unbonding atoms are now available!!
  • user account receives tokens
  • user's bonded atoms are slashed
  • user's bonded atoms are revoked
  • user made income in atoms!
  • new proposal was created in governance
  • the proposal you voted on failed!
  • the proposal you voted on succeeded!

Users can also click on it to launch Voyager instantly.

@nylira nylira mentioned this issue Jun 27, 2018
5 tasks
@cwgoes
Copy link

cwgoes commented Jun 28, 2018

I agree; the second transaction UX is terrible. voyagerd might work, but if this really would require something of that magnitude (unless you were planning to do it anyways), maybe we should revisit this on the SDK end.

@jbibla jbibla added the discuss label Jun 29, 2018
@faboweb
Copy link
Collaborator Author

faboweb commented Jul 2, 2018

I agree with Chris. If this has such a big scope, let's look for another solution first.

@jbibla
Copy link
Collaborator

jbibla commented Jul 3, 2018

love the idea @nylira !

but if we can make the change on the SDK then that would be a lot easier!

@cwgoes any updates?

@cwgoes
Copy link

cwgoes commented Jul 3, 2018

@cwgoes any updates?

On our radar but not going to happen this week, made an issue in the SDK repo - cosmos/cosmos-sdk#1525.

@faboweb
Copy link
Collaborator Author

faboweb commented Jul 10, 2018

Linking #148

@faboweb faboweb added blocked ✋ issues blocked by other implementations/issues split 🍌 issues that need to be split into several smaller issues with reduced scope and removed blocked ✋ issues blocked by other implementations/issues labels Jul 10, 2018
@faboweb
Copy link
Collaborator Author

faboweb commented Jul 17, 2018

  • refactor LCD endpoints
    • David + Fabo
  • adding transaction to history page
    • Fabo + Jordan
  • filter by transaction type in history
    • Peng + Fabo

@faboweb faboweb removed the discuss label Jul 17, 2018
@faboweb
Copy link
Collaborator Author

faboweb commented Jul 24, 2018

Split 🍌

@faboweb faboweb closed this as completed Jul 24, 2018
@cwgoes
Copy link

cwgoes commented Aug 17, 2018

Note: cosmos/cosmos-sdk#1525 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design-work-needed 🎨 issues that require design work before development split 🍌 issues that need to be split into several smaller issues with reduced scope
Projects
None yet
Development

No branches or pull requests

4 participants