Following the designs

We need to implement the new widgets.

We need to remove the Equity asset salary and just show the base one

We need to think about how we want to handle the request salary workflow

Right now we have this beautiful design but if the payroll is configured to work with vestings we need to have a way to display to the user the remaining vestings that he will be able to do with the address provided.

Once the address reach to 50 vestings we need to disable the possibility to choose equity token for the payroll and let the user know that if he wants to be able to be paid with equity token again he needs to change their address.

Also we need to display here the max amount available to be requested and let the employee choose if he wants to request all the amount or less.

See https://www.figma.com/file/nKZowkSjFJm6yL6ITSEaCw/Payroll?node-id=228%3A1176

Payroll Functionality

Payroll provides an intuitive way for an organization to bootstrap when capital and/or cashflow is limited. Members who are added to payroll are assigned a rate in terms of a base, cash-like asset such as dai and then are able to withdraw that amount of the cash-like asset or instead opt for deferred compensation in the form of an organization's native token or reputation (subject to vesting) per period.

The offered rate for deferred compensation is always a multiple of the base amount and it can be a fixed value updated by the organization periodically.

Redemptions

Redemptions allows for holders of an organization's native token or reputation, which has been fully vested to burn it in exchange for a proportional share of assets held by the organization.

Weird interactions and intuitions about multipliers

A member holding fully vested tokens or reputation may choose to redeem their tokens or reputation for a proportional share of the organizations current assets.

Then if they are currently on payroll they may opt to receive new tokens or reputation (subject to vesting) instead of cash. This is a weird interaction because it is both removing cash and or other assets from the organization, while at the same time deferring a cash payment in order to bet on the future value of the organization.

With both redemptions and payroll installed in an organization there becomes a clear relationship between how the organization's members value the expected future potential of the organization and that provides an interesting lens to evaluating deferred compensation and multiplier policies.

When an organization holds only the base payroll asset

If the base payroll asset is the only redeemable asset understanding it becomes fairly intuitive to think about deferred compensation and parameterizing the multiplier.

We can assume that current value of tokens or reputation must be equal to or greater than their current redemption value. The premium between the current redemption value will be due to speculation, and each individual may have a different valuation model and reach different valuations leading to different preferences for cash versus deferred compensation.

However, if the multiplier is set such that current redemption value is greater for the deferred compensation model than the multiplier should almost certainly be reduced, potentially even bellow 1.

When an organization holds other assets besides dai

If an organization is holding other assets besides dai, perhaps ETH, ANT, Chai, or cDAI. The intuition is the same, but it is important to consider the value of all redeemable assets relative to the payroll's base asset and multiplier.

Considering vesting restrictions

If vesting restrictions are applied to deferred compensation (they likely should be), the option to defer compensation clearly becomes more risky than if those assets could be sold or redeemed immediately.

If tokens can be redeemed for 100 dollars today, but cannot be redeemed or sold until they have vested, then by the time they are vested they could easily be worth 50 or even 0. So if you are offered a 100 dollars today, you might find it would take the equivalent of 200 dollars worth of tokens subject to vesting restrictions at present value to be considered equivalent compensation.

When should an organization offer deferred compensation

When an organization is bootstrapping it does not necessarily have much or potentially any cash on hand. In these cases in order to incentivize contributors it must be able to offer deferred compensation, and likely the multiplier between a hypothetical cash payment and and deferred compensation should be relatively high, as the success of the organization and future revenue potential is completely un-proven. Contributors are allocating their time to the project and potentially forgoing other opportunities to exchange that time for cash to do so, providing a high multiple during this phase makes sense.

After an organization has established a product and is producing stable revenue it is much less clear whether deferred compensation should be offered at all, let alone at a multiple greater than one. When an organization can pay market rates, and the members of the organization believe that the value of the organization will grow in the future then they may not want to allow themselves to be diluted at all.

However, in some cases even stable organizations that can afford to pay market rates to compensate workers would like to offer a deferred compensation option because workers who are also owners tend to be more effective and more aligned with the long term interests of the organization as a whole. In these cases it may make sense to offer deferred compensation (subject to vesting) at multiples close to one, and If the organization uses reputation and therefore not possible to simply use cash for to acquire a stake in the organization it may even make sense to use multiples less than one.

We have 2 possible modes for the request salary panel

• When there are remaining vestings available - design

• When no more vestings available for the account - design

Currently the background script fetches employees data on every update event (e.g add employee accrued salary, change employee salary, etc). There is the problem where if users are terminated and do their last payday, the employee record is deleted from the contract.

This means we shouldn't rely on contract calls for fetching employees data but to use the logged data from events to perform state updates.

Some functions changed with the code cleanup #11, so we need to re write the tests accordly

We need to display info about the finance on a widget

Design.

• Need to remove the trx hash and add it to dot actions menu.

Since we are not using anymore the USD , we need to create a new component that displays the stats for the payment token and the equity

It might be something weird compatibility wise with the client and this old app.

I removed validation when modernizing the app. We should validate it using the new practices.

Since we want to avoid multiple transactions to update this parameters

Update PayrollKit to PayrollTemplate and start using @aragon/templates-shared

Each time an employee is getting his salary via payday function the accruedSalary is set to 0. But what if his _requestedAmount is less than accruedSalary? In that case all his accruedSalary will be terminated without payout.

Design

Research and first implementation about the multiplier.

Move from outdated @aragon/client

Loving the bee one :) but we need a generic one

Design

Shared component with #46 So we might want to have different modes

A more interesting case for wanting to give users an option between receiving their payroll in different assets is the distinction between "cash" and "equity", where a user may opt to receive a portion of their agreed upon salary as tokens/rep/equity.

Unlike receiving different capital assets this provides a relatively unique benefit for both the organization and the user. For early stage organization there may be relatively little cash on hand, but the organization can negotiate a market based compensation arrangement and the user can receive equity at a fixed (or dynamic) rate.

This helps organizations bootstrap, while being fair and equitable to contributors who are forgoing a fair market salary.

Unlike #1 this option would not require pricefeeds as token option can be priced relative to the base currency as it does not itself have a fair market value.

• An organization should be able to adjust the multipliers or turn off the option via a role.
• The rate offered for minting tokens is relative to the base currency amount, and would be a multiplier. eg if the user has a salary of 100DAI and the multiplier is 4x they can mint up to 400 of the equity asset per period.
• The multiplier is fixed and can be updated with a role.

Convert Template.sol example to use Aragon buidler hooks

Following Dandelion docs we need tech docs and user manual for the app

Continue modernization begun in #9:

• Modernize tables (use DataView)
• Modernize filters (use DateRangePicker and others)
• Modernize Transaction label (use TransactionBadge)

We need to change the buidler hooks in order to work with the new payroll smart contract

See Spec in issue

Add github readme

Reference docs: slicingpie

• Add illustrations
• Display relevant data

Request Salary side panel

• Consider using debounce as described here: https://levelup.gitconnected.com/debounce-in-javascript-improve-your-applications-performance-5b01855e086 or using the approach I've used here: https://levelup.gitconnected.com/debounce-in-javascript-improve-your-applications-performance-5b01855e086 with the slider input to prevent calling the API more than necessary.

• Update the top info box to include at the end "Requesting any salary under the total available will forfeit the remainder."

• Update the vestings warning at the bottom with something like heading "Equity Payments Limit" (if there can be a heading) and description "This address can request equity up to 50 more times while vesting is enabled for equity payments."

• In the radspec string, not sure if it's possible but can we calculate the amount returned in DAI and the amount in equity and display that to the user? Eg for 40% equity, with 4x multiplier and 100 DAI of max available 150 - "Request 60 DAI and 160 Equity Tokens from your salary and forfeit 50 DAI unclaimed."

New Employee side panel

• Change "Salary" to "Yearly Salary"

• Again could the radspec definition be updated to calculate the amount of the yearly salary or is it not possible? It could read "salary of 10000 DAI per year" instead of "salary of 0.0123 DAI per second".

Edit Equity Option side panel

• Edit Equity Option side panel could do with an info panel like title "Action" description "Update the equity options which are applied for each equity request. Including the multiplier which is against the base asset.

• Also in the radspec, the % sign comes after the value not before (guess it's different in other languages though).

Elsewhere

• In the My Payroll tab -> Previous Salary table could we include the amount of the equity token transferred too? I'm pretty sure it's in the event.

• I see there's no way to terminate an employee, I don't know if this is necessary but imagine it should be available on the UI. Has it been discussed?

Use the new aragon ui chart component in order to represent the salary earned both: base token and equity token.

chart component

we need to use the same existing calculation on the base token for the equity token

Design

With the new builder plugin for the aragon apps the tests needs to be migrated to truffle 5.
The following links might be useful:

https://hack.aragon.org/docs/guides-buidler-migration
https://medium.com/coinmonks/upgrading-to-truffle-5-22aedc7c2a4d

Remove unnecessary code from the smart contract that is not going to be used like Price oracle and the multi currency payment support

We need design for the new form (we are not going to ask for the name)

We also need to do a refactor for this screen since is using an old React version and as we touch components will be good to do a cleanup and stick to the 1hive-aragon new coding styles.

• designs changes needed #30 and #31
• add removed validations on #15

One of the biggest sources of complexity in the payroll app is enabling employees to choose which asset or mix of assets they want to accept each period. This requires relying on a price oracle for each asset and imposes an unnecessary treasury management / budgeting challenge on the organization.

Rather than allow users to select from eligible assets we should simply things by only supporting a single asset.

When withdrawing salary, the employee need to be able to specify some fraction of the total balance that has accrued in base asset. (eg I've negotiated a rate of 50 dai an hour, I worked 10 hours since last time I request pay, I will request only 500 dai, even if if I technically have permission to withdraw more than that).

So basically we are going to trust on the employees that they are not requesting more than what they should do and if that behaviour is detected the org can take some action against the employee

So in order to allow the employee request less than the max amount accrued we are going to reset the accrued balance as if the employee had withdrawn the full amount.

If for some reason the employee by mistake select less than it should be that needs to be handled within the org members in another way (like a finance transfer)

• My payroll: Dataview - remove trx and add it to the action buttons

• My payroll: Dataview - remove status

• Team payroll: Remove salary burn rate widget

• Team payroll: Remove action buttons from dataview

When someone opts to receive tokens or reputation instead of a cash payment, they are generally making a bet on the future value of those tokens or reputation. For the organization they are being diluted in exchange for avoiding an immediate cash payment.

In cases where tokens are liquid or even redeemable (eg via redemptions app) this option becomes extremely favorable for the person making the choice as opposed to the organization making the offer. In order to make the dynamic more interesting for the an organization, we should enable the organization to impose vesting restrictions that prevent the tokens/reputation from being sold or redeemed for some period of time after the grant.

Design

We need to add the status (active, inactive) column