1hive / redemptions-app Goto Github PK

I think the solution that @ajsantander made for his app is more intuitive and practic than what we currently have. Check the code here

We should be able to write a token address in a text field and save it to the redeemable token list if the token exists on the vault.

Seem to be getting stuck here. not sure why... any ideas?

TODO:

• Test for Redemptions.sol

• Test for ArrayUtils.sol

Use @aragon/api latest version which includes default events

Since we're building this for other people, getting their opinions seems critical. When we're ready to launch the app (or right before) it would be awesome to have a bounty for user feedback. The intention is to provide a small token of gratitude for people who take the time to checkout the app and give us actionable feedback.

Feedback Bounty program draft can be found here:

• https://github.com/burrrata/AAC/blob/master/user-feedback-bounties.md

Questions

• Are amounts of 100, 300, and 500 HONEY as described in the draft appropriate for user feedback?
• What other questions do we want to ask people? What do we need feedback on the most?

I think we should consider to update the initialize function to not include the array of addresses. Right now is not possible to use an array option on the aragonCLI so this change will improve the workflow when trying to install from aragonPM

Originally posted by @0xGabi in #19 (comment)

Should include:

• audit status
• how to run/test
• how to deploy
• how to interact

Should show user the current exchange rate between the token and vault assets.

Should allow users to click a redeem tokens button, and then enter the amount of tokens they want to exchange and preview the assets they would recieve in exchange before confirming the transaction.

Based on the conversation here: 1Hive/dandelion-voting-app#5 (comment)

If we want redemptions to behave well with the dissent oracle, we cannot allow redemptions through forwarders.

We have essentially two options here, we can expose two redeem() functions and roles, one allowing direct redemption (not through forwarders) and one allowing redemption more generally.

Or we can simply adjust our implementation to only allow redemption directly.

The only compelling case I can think of for redeeming through a forwarder is with something like Tollgate where a fee could be imposed on redeeming. But I think thats probably not that important to support, and it may make sense in the future to just create a configurable penalty parameter in redemptions, to discourage exit.

So my suggestion is to simply update the redeem function to only support direct redemption. (This essentially discards the work we did to support forwarders through signatures/and recovery which is an interesting pattern, but 🤷‍♂️) I think that was a more important requirement when we thought we would be implementing the dissent logic in a forwarder and not in an ACL oracle.

Add solidity-coverage to run on CI integration.

Following the mockup create the signer panel

When trying to redeem tokens with a 18 decimal units the front broke

After installing Redemptions app on Rinkeby with the command show here:

aragon dao install <dao-address> redemptions.open.aragonpm.eth --app-init-args <vault-address> <token-manager-address>

And creating one of its permissions (ADD_TOKEN_ROLE) with the following command:

aragon dao acl create --environment aragon:rinkeby 0x88D96395F381Cee3ed834A68880F68c93267f809 0x6E3C81907343335B71a95ae6198fa2d42E08C8CB ADD_TOKEN_ROLE 0x18D8D4fcC706DA09E8329d330059a0a8bE916c27 0x18D8D4fcC706DA09E8329d330059a0a8bE916c27

The app appears in Permissions and Settings but not in the Apps section. It seems that the frontend is not loaded. In Settings the app is marked as "CONTRACT-ONLY".
The only relevant message I see in the console is this one:

You can see the DAO here:

https://rinkeby.aragon.org/#/0x88D96395F381Cee3ed834A68880F68c93267f809

Am I missing any step?

Thanks.

TODO:

Start using a fork of the aragon/deployment repo.

Currently removing a token requires a user to input the token contract address, but since the user is clicking on the specific token icon in order to remove the token it would make sense for this to be inferred from that action.

Redemptions.ERROR_VAULT_NOT_CONTRACT (Redemptions.sol#21) shadows:
- VaultRecoverable.ERROR_VAULT_NOT_CONTRACT (@aragon/os/contracts/common/VaultRecoverable.sol#18)

Remove the state variable shadowing.

The instructions to run the Redemptions app do not include necessary dependencies. It would be great to add ALL of the info someone needs to run and hack on the app. This means everything someone would need to get started from a fresh install of any OS.

This is systemic problem across the Aragon ecosystem. Let's not perpetuate a frustrating dev experience. It needs to be easy for someone, anyone, to read the instructions, get the app running, and hack on it and contribute.

To me this looks like specifying the version of npm/node used, the setup for the aragon cli, and any other processes that might need to be running for this app to work.

Change Rdemptions to Redemptions

We can remove babel dependency after

100 HONEY Bounty for user feedback on Redemptions UI and documentation.

Some are in dark mode, some are light, but they are not all the same. They should all be the same.

I was wondering if it would make sense to implement the history of redemptions made, like some sort of table.

testing from zenhub

The requirements would be pretty simple:

1. The app would be initialized with a vault address and a minime token address
2. The app should maintain a list of tokens
3. Users could burn any amount of minime token and be transferred a proportional amount of the balances of token in the lis that are stored in the vault.

For example if there are a total of 100 Merit tokens in the supply, and I "redeem" 10, I would be transferred 10% of the balance in the vault of each token in the list.

For simplicity, we can limit the scope to only track a single vault asset.

When we add an address with the addToken method that don't implement the ERC20 interface the Redemptions app will broke until this address is removed from the token list.

Two possible solutions are:

1. We could handle this in the frontend to prevent the app to stop working.
2. We could improve the smart contract check to prevent this kind of address to be added.

The token manager allows tokens to be assigned as vested, meaning they are not immediately transferrable but unlock over a vesting period.

Currently redemptions would allow the user to redeem tokens even if those tokens are subject to a vesting period.

I can imagine situations where an org would not want to allow redemption for tokens which are currently being vested, as there is not a clear owner of partially vested tokens (vesting can be revoked).

To account for this we may need to have a setting for redemptions which determines if vesting is respected, and if this setting is on we would need to validate that the user is not trying to redeem more than their fully vested token balance.

Get this ready for a security auditor or allow devs to work with it.

My understanding from our conversation today is that right now the current implementation will only work if we allow ANY_ENTITY the ability to redeem, or we explicitly define addresses which can call the function.

Assigning the role to a Token Manager to allow anyone with tokens to call the redeem function through forwarding will not work, because the redemptions-app will not be aware of the true message sender.

Is this a correct interpretation? And is this issue relevant?

Token list component with the available balance

Currently the background script only listens for redemptions contract events.

If new redeemable tokens are minted/burned, the RDT total supply should be refreshed (even current account's RDT balance in case it was the target address ).

Same thing happens with vault deposits/withdraws.
If the deposit/withdraw token address is currently added in the redemption token list, it should refresh vault's token balance.

Currently you'll have to refresh redemptions app in order to see the changes.

Upgrade app to start using the new @aragon/ui 1.0.0 once released

I have tried deploying redemptions on Aragon 0.8 Camino with the Agent app. I also deployed 'Vault' as it was missing from the webapp rinkeby build. I used the Aragon-CLI to assist in getting this done.

I ensured that TRANSFER_ROLE permission on Vault and the BURN_ROLE permission on the Token Manager is done.

My organisation contract on rinkeby is 0xEDEd31e0788C8D102dDd1850705654FDe82B17ac or https://rinkeby.aragon.org/#/v1adl/ that I am testing and playing around with.

I can add token id for redemption, I can remove token id for redemption. And my redemption is linked to my vault as it is reflected there. But I am getting this Error when I tried to 'Redeem' on the Redemptions app:

Action impossible
The action failed to execute. You may not have the required permissions.

I followed the permissions and settings as in the webapp demo on https://rinkeby.aragon.org/#/tryredemptions. Is there some permissions that I'm neglicting.

It would be awesome to have a bug bounty.

Right now we can only offer HONEY, but soon we'll be able to offer DAI as well.

Until the app is actually released I think it makes sense to offer HONEY as a bug bounty

• 100-250 for a minor issue
• 500 for something that could impact the user experience
• 1000 for anything that affects funds

Once we've frozen the codebase and are prepared to release the app in the wild, then we can augment the bug bounty with DAI. This can be used to invite the community to check out our code. If any vulnerabilities/snafus are discovered, then great! If not, then it serves as insurance to hopefully protect future zero-days (like 0x just experienced).