Single-Sided Staking Abstraction

[cjthompson]

What should a single-sided staking abstraction look like?

import type { BigNumber } from 'bignumber.js'

export interface Investor<T = unknown> {
  initialize: () => Promise<void>
  findAll: () => Promise<Array<InvestorOpportunity<T>>>
  findByAddress: (address: string) => Promise<unknown>
}

interface RebasingToken {

}

interface ApprovalRequired {
  isApprovalRequired: true
  allowance: () => Promise<unknown>
  approve: () => Promise<unknown>
}

interface Reward {
  isRewardClaimable: true
  claim: () => Promise<unknown>

  readonly rewardAsset: {
    assetId: string
    balance: BigNumber
  }
}

interface DelayedWithdrawal {
  delayInMinutes: number // 14 * 24 * 60 = 14 days
  inProgressWithdrawals: []
  withdrawWithDelay: () => Promise<unknown>
}

type SerializedTX = string

enum Fee {
  High,
  Medium,
  Low
}

abstract class InvestorOpportunity<T = unknown> {
  static create: <U = unknown>(details: { address: string }) => Promise<InvestorOpportunity<U>>
  readonly id: string // opportunity address (contract address / validator address)
  readonly displayName: string
  readonly isApprovalRequired: boolean = false
  readonly underlyingAsset: {
    assetId: string
    balance: BigNumber
  }
  readonly positionAsset: {
    assetId: string
    balance: BigNumber
  }
  readonly apr: BigNumber
  readonly price: BigNumber // in terms of USD? - maybe not needed in here
  readonly supply: BigNumber
  readonly tvl: BigNumber // total volume locked for the entire opportunity
  readonly metadata: T

  withdraw: (amount: BigNumber) => Promise<unknown>
  deposit: (amount: BigNumber) => Promise<SerializedTX>
  signAndBroadcast(tx: SerializedTX) => Promise<unknown>
}

class CosmosInvestorOpportunity extends InvestorOpportunity<unknown> implements Reward {
  readonly isApprovalRequired: false
  readonly isRewardClaimable: true
  claim: () => Promise<unknown>
  private lastFee: { [k: keyof Fee]: BigNumber }

  redelegate: () => Promise<unknown>

  // Fee UI will call `setFee` onClick then `deposit` call won't need to know what fee was selected
  getEstimatedFee: (type: Fee.Deposit | Fee.Withdraw) => Promise<{ [k: keyof Fee]: BigNumber }>
  setFee: (fee: Fee) => void
}

[0xdef1cafe]

few extra methods we'll probably need here off the top of my head

• isApproved - is an address already approved to interact with a contract
• withdrawInstant - e.g. yearn has no timelock, FOXy does
• withdrawDelayed - as above
• getBalance - how much does a given address have locked in the contract?

i know @toshiSat had some comments about the way tokemak named some of their methods on the ABI - standardizing on that terminology now will help. e.g. they were using wallet over userAddress

[cjthompson]

isApprovalRequired is the flag I was thinking of to know if a contract needs approval. For things like cosmos that don't need approval, that value would just always be false.

[toshiSat]

Currently we are polling to check for allowances, I think if we had an isApprovalRequired it would be fine. isApproved is probably also good because for ETH chains we could just return true if allowance[user] > 0 and poll it from the front end.

I don't like wallet over userAddress 😂. That felt so weird to me

[0xean]

@cjthompson a few questions

1. readonly address: string - what address is this specifically?
2. readonly assetIds: { staking: string; reward: string } I assume staking is the token being staked and not the token being return to the staker? For example Tokemak. I stake FOX and get back tFOX and am rewarded in TOKE. Is FOX the staking asset? What is tFOX in this interface?
3. If we need to index these, how are we doing so? For example with IDLE, the underlyingToken for them may be USDC and there may be 3 staking contracts that accept USDC, and each on of those has a tranche (AA or BB).

[cjthompson]

Fees

I feel like we still need to nail down how we're going to handle fees, whether there's a common method or that fees are protocol/chain specific.

I think the later might be good and we could have different fee components that are plugin specific since fees are handled very differently between protocols/chains.

[theoboldfrazier]

I like that latter. Fees could be a function alongside withdraw and deposit with chain specific implementation.

[theoboldfrazier]

I think overall this looks good, with the question of fees having a direction toward abstract class declaration with chain specific implementation.

The only thing that stands out in the abstract class to me would be the isApprovalRequired. I think that may not apply to some chains and may better fit on the Ethereum specific implementation.