Deploy the bond and broker contract to testnet so that they can be used in porter-finance/frontend#6

@Namaskar since you mostly worked on this I'd like to hear your thoughts on the technical and testing complexity that multiple collateral types has over single collateral types

Interaction with Gnosis Auction

Options

We have three main options on how to interface with Gnosis auction

1. Use the contract as-is from the deployed address (recommended)
2. Fork the contract and redeploy without changing the source code
3. Fork and edit source code for a custom use case

Use the contract as-is from the deployed address (recommended)

• More trust from users - they can see there's been over 30k transactions to this contract.
• Users are confident that the auction code has not been modified & has the same level of security as the original
• We can interact directly with both their testnet + mainnet deployments without any deployment overhead.
• Technically gnosis auction has the ability to add a fee - but two separate developers said they will not be.
• Possibility for us to use their subgraph instead of implementing it ourselves.
• Our auctions will show up in Gnosis auction UI.
• Recommended path from Peteris.

Fork the contract and redeploy without changing the source code

• No quick way for users to tell that this fork has not been modified.
• Redeploying the contract would cost 5m gas (.5 eth @ 100gwei).
• Our auctions would not show up in Gnosis UI.
• All porter data would be isolated.

Fork and edit source code for a custom use case

Add's more auditing overhead, protocol risk, and complexity. Avoid if possible.

Questions

If we want to take some sort of fee for facilitating or send a fee to the Sherpa, how would we do that?

There are a few different ways we can handle this:

1. Take a certain number of the bonds after they have been created. These can either be sent to the porter treasury or distributed to sherpas. In the current implementation - the entity that creates the bond (broker contract) would be sent all of the bonds after creating them. The broker contract could keep 3% of the bonds and then send the other 97% of the bonds to the borrower.
2. Take a certain % of the borrowing tokens or bonds after a successful auction. If we initiate the auction from our Broker - it will be the auctioneer. It would receive the borrowingToken upon the settlement of the auction and could keep 2% them and send the rest to the borrower (recommended)

@Namaskar-1F64F please correct me if I missed anything

We are leaning towards using a BondFactory to deploy a new ERC20 bond token before each gnosis auction and using the bond token as the auctioningToken

https://ropsten.etherscan.io/tx/0x387efb77e56e0b3f6066c8a853464c9a4b1b24ffbf0d49a0063793168f058638

2,271,956 gas to deploy current bond contract

https://ropsten.etherscan.io/tx/0xc164917ff5f918aec456e8d9912bd40ea9fc2715a69177093b421a93c6d2c498
1,154,924 gas to deploy very basic erc20 token

@ 100 gwei
100k gas = .01 eth
1m gas = .1 eth
10m gas = 1 eth

So ~ .2eth ($500) to deploy a bond contract - This seems like a lot but might be negligible to the DAOs issuing debt

Are there ways we can reduce these costs significantly?

https://github.com/optionality/clone-factory - would something like this be an option? Repo is quite old

It was decided to allow borrowing to use any ERC20 token as collateral - #28

We need to make sure to protect against malicious tokens.

What would it look like for us to support multiple collateral types?

Imagine an issuer would like to collateralize each bond with multiple types of collateral.

For example: each bond would be backed by 10 ABG (AlwaysBeGrowing Governance Token) and 5 ABC (AlwaysBeChanging Governance Token) and should be convertible into 2 ABG and 1 ABC tokens

1. Ratio Based

We could accept a collateralization ratio and a convertibility ratio for each token individually. These numbers are then used when dealing with any of the methods that interact with the collateral.

Collateralization ratio

To get the numbers in the example above - the collateralization ratio for ABG would be 1:10 and the ratio for ABC would be 1:5

Convertibility

Example convertability ratios would be 1:2 for ABG and 1:1 for ABC. This means a user could call convert to burn one of their bonds for 2 ABG and 1 ABC tokens.

2. Bucket Based

An alternative method would be to define the ratios of each type of token that will be backing the bond. For example - the backing ratio could be 1/3rd ABC and 2/3rd ABG tokens. The backing ratios must always add up to 1.

We can refer to the backing ratio as a bucket. So one bucket is .333 ABC + .666 ABG

The backing ratio would be provided at bond creation and would not be configurable after creating a bond.

Collateralization ratio

This would be how many buckets are backing the bond. A collateralization ratio of 1:15 would mean that 10 ABG tokens 5 ABC tokens would back each bond.

Convertibility

The convertibility ratio would be bond:bucket - so convertibility ratio of 1:3 means that each bond can be converted at any time for 3 buckets worth of bonds. So, 1 bond can be burned for 1 ABC and 2 ABG tokens.

Questions

• initialize in our bond contract would need to accept an array of collateral types. @Namaskar-1F64F is there a limit here? What would be the max array items a caller would be able to add?
• How would the ratios be stored?

Figure out what we need to do to adapt EasyAuction to our use case.

Questions:
How to send out bond tokens on successful auction?
Where should collateral be stored?
Multiple EasyAuction contracts or just one?

Currently when creating a bond we are going towards a pattern where the Broker creates the bond and becomes the "owner". The issuer has some special privileges on the bond itself like withdrawing collateral. Who should own the bond and what permissions should each action have?

How should the bond tokens be named @jordanalexandermeyer ? I know this was discussed previously but I'm having trouble finding out where.

Need tickers as well

Trading platform

This will allows investors to trade their bonds which is one of the big value adds of bonds. They are liquid and tradable while loans are not. This is a high priority.

Balancer Metastable Pools

https://docs.balancer.fi/products/balancer-pools/metastable-pools

Bond AMM:

https://yieldprotocol.com/YieldSpace.pdf

Hifi AMM (based on yieldspace)

https://github.com/hifi-finance/hifi/tree/main/packages/amm

Unofficial Technical Roadmap

This is a rough technical roadmap of what needs build for our initial vision. Timeline is subject to change. Many of the items can be done in parallel.

gantt
    title Unofficial Technical Roadmap
    dateFormat  YYYY-MM-DD
    excludes    weekends

axisFormat %b-%d
Secureum CAREX Report : milestone, m2, 2022-04-07, 0d
Audits Finished : milestone, m3, 2022-05-11, 0d
Testnet Ready : milestone, m4, 2022-05-13, 0d
Launch Week :milestone, m5, 2022-05-23, 0d


    section Frontend
    Core Page Design           :active, a1, 2022-04-01, 31d
    Auxiliary Page Design     :a2 ,2022-04-29, 3d
    section Smart Contracts
    Pre-audit fixes      :active, b1, 2022-04-07  , 7d

    section Audits
    Zellic          :c1, 2022-04-18, 5d
   Spearbit     :c2,  2022-05-02 , 7d

section Confrences
Permissionless :e1, 2022-05-16, 5d

0-3 Months (May mainnet launch internal goal) (July mainnet is public date)

• Branding, product, landing page designs: (ETA end of February) (handled by VectorDAO)
• Landing page built (outsource?) @jordanalexandermeyer
• Subgraph built @RusseII @luckyrobot
• V1 smart contracts developed - all functionality outlined in our protocol spec is implemented @Namaskar-1F64F
• Internal audit (Get help from Peteris and Stu?) @RusseII @Namaskar-1F64F @luckyrobot
• Testnet testing
• Make contracts public + add gitbook technical documentation @RusseII
• Pre-Audit with Secureum CARE-X (March 24-31) @Namaskar-1F64F
• External audit @RusseII with Zellic (~April 18th-April 22nd)
• Smart contracts finalized @Namaskar-1F64F (April 17th)
• External audit @RusseII with Spearbit (~May 2th-May 11th)
• Core frontend pages release ready @luckyrobot
• Immutify Bug Bounty @RusseII
• V1 testnet release
• V1 mainnet release
• Auxiliary frontend pages built @luckyrobot

3-6 Months

Explore governance

Explore tokenomics
Porter REFI

Trading platform
This will allows investors to trade their bonds which is one of the big value adds of bonds. They are liquid and tradable while loans are not. This is a high priority.

Credit default swaps
This will allow investors to hedge themselves when purchasing bonds

Bond ratings on demand
This will be helpful but Prime is working on this and it isn't a high priority.

Backing debt with a lien on the treasury or project token mint function
This will make debt much more trustless.

Ideas

#128
porter-finance/frontend#7

Resources

https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/
https://docs.porter.finance

@jordanalexandermeyer Do we want an issuance fee for our V1?

If I remember correctly:

• We want to take the fee in bonds every time new bond tokens are minted.
• 2% fee

Broker pattern vs token pattern

We have the option of having the broker contract act as an intermediary that handles the main functionality of our protocol (broker pattern) or we can implement this functionality on each of the different tokens themselves (token pattern)

Do we have one broker contract that holds all the collateral, handles convertability, handles repayment, handles bond redemption for each of the bonds? Or should we implement that logic on the bond itself and limit the functionality of the broker to just deploying the bond tokens?

• AAVE uses the broker pattern while Compound uses the token pattern

• We will be deploying a new bond contract for every single auction. For gas savings - we may want to keep the bond functionality minimal (Broker pattern). This may not be an issue if we follow the clone pattern for new bonds. This will be explored further in #15

Bonds should be decoupled from gnosis auction. Gnosis auction is just a mechanism for selling the bonds. They should be designed in a way where they could be sold directly to lenders - or through other means.

Do we want to have the Auction for v1? Would it make sense to let borrowers decide the bond interest rate and allow investors to purchase the bonds at that given price instead of an Auction?

This would allow us to ignore the complicated mechanisms of gnosis auction and figure out of the demand for issuing / buying bonds is there.

Collateral types

• Do we want to whitelist collateral addresses? Or allow borrowers to use any ERC20 token as collateral?
• Should DAOs be able to deposit multiple collateral types per bond? @jordanalexandermeyer (this may complicate Convertibility)

https://github.com/trailofbits/eth-security-toolbox run slither on the code - maybe these other tools would provide useful insight as well?

Originally posted by @Namaskar-1F64F in #61 (comment)

@RusseII to run this to unblock

bug from https://docs.google.com/document/d/1672FR7GSqtFlPWd_p2E5fn1oJqvMcIdCZBPcqCpUGGA/edit

for the bond redeemBond() function

Walk through a few examples of inputs and outputs from easyAuction to make sure we fully understand how it works and that it makes sense to use for our protocol

Example: DAI as borrowing asset
Max interest rate: 10%
Term length: 1 year
Min issuance size: 50m
Max issuance size: 100m

From #74 (comment)

Instead of determining the amount of tokens the user is allowed to mint in this step, can we accept supply as a parameter in the constructor along with convertibleTokens and collateralTokens?

supply + convertibleTokens will give the convertible tokens / bond
supply + collateralTokens will give the collateral tokens / bond

Issuers can't mint tokens until the correct amount of convertibleTokens and collateralTokens are deposited. And they can only mint supply tokens.

Thoughts?

https://github.com/orgs/porter-finance/projects/10 - I created this board that should track all the different tasks we need to complete on our smart contracts before our pre-audit.

Can you please add anything you think is missing before EOD Thursday?

In Maple's contracts, they have an isLoan function in their LoanFactory here. I assume this is used to check if a contract address is a Maple loan. Also, they keep a list of all the loans here.

I propose @RusseII look into whether we should have these functions on our BondFactory.

We can have bond issuers go through the broker to create bonds. This would make the Broker "owner" of the bond. On the other hand, issuers could create bonds directly through the bond factory itself.

What benefits does having the Broker be the owner provide us? Should we purposefully disallow creation of bonds if the issuer does not go through the broker contract?

Fractional has an API which is going to make it suuuuuper easy for us to accept Fractional vaults as collateral for bonds.
https://mainnet-api.fractional.art/vaults/0x6725363E565BAA1dda45d492810298ae0b25c4ac

Our contract will be accepting different collateral tokens and handling different borrowing tokens. These tokens may have different amount of decimals defined. How do we handle the division amongst collateral receivers with variable decimals?

https://github.com/Rari-Capital/solmate/blob/main/src/mixins/ERC4626.sol#L128 defines ONE variable using the number of decimals passed in, but i'm not sure how it's being used after that.

• Create repo (public)
• I'm thinking we use https://github.com/paulrberg/create-eth-app but up to @luckyrobot
• TS or JS? I'm thinking TS but up to @luckyrobot
• CSS framework? I'm thinking tailwind https://github.com/porter-finance/handbook/issues/24 but up to @luckyrobot
• Setup deployment - I'm thinking Vercel but up to @luckyrobot
• Add same license that's in our other repos

Any other frontend pre-work that we can do before we get the VectorDAO designs?

https://www.auditless.com/codex/how-to-do-a-security-review

Upgradability

Refi

In the future - we will add a way for users to refinance their bonds with a refi vault.

We added two roles to facilitate this - the WITHDRAW_ROLE and the MINT_ROLE

Refi vault user flow:
Issuer makes new Simple/Convert product
Issuer makes new Refi vault
Issuer grants the MINT_ROLE of new product to Refi vault
Issuer grants the WITHDRAW_ROLE of old product to Refi vault

This would allow the refi vault to create new bonds and use the payments to repay the old bond and withdraw the collateral.

General

There is nothing else specific for upgradability built into the contracts. After a new bond is made it is immutable and can never be changed. Upgrades will come from up deploying new versions of the BondFactory contract and updating the contract used by our frontend.

https://thegraph.com/hosted-service/subgraph/create?account=All%20Subgraphs

Should we store description on chain?

https://ethereum.stackexchange.com/questions/11556/use-string-type-or-bytes32

Gas cost is 20k gas per 32 characters.

Example: It would be 140k gas to store this on chain:

Bribe Protocol aims to revolutionize dGov with incentivized protocol participation. Improving upon current DAO governance models, Bribe coordinates voters into powerful coalitions up for auction by a highest bidder.

(215 characters / 32) = 6.7 rounded up is 7
(20k gas * 7) = 140k

@ 100 gwei
100k gas = .01 eth
1m gas = .1 eth
10m gas = 1 eth

Pros

Cons

See if this is something we should handle on smart contract side or off chain.

https://rari.app/fuse would be good to check out how they handle it

add events to (state change list?) and what necessary data is required for frontend and monitoring

The balanceBefore - balanceAfter logic in the bonds is to prevent the incorrect accounting of the actual balance of the token being out of sync with ours. this is from https://github.com/OpenZeppelin/workshops/blob/master/11-dangers-token-integration/slides.pdf
and two examples

Now that we are selling overcollateralized convertible bonds without liquidations - the price of bonds can change significantly based on the price of the underlying collateral.

If the price of the collateral drops below 100% collaterialization ratio - the bonds will drop in price
If the price of the collateral appreciates so it's profitable to purchase the bonds and immediately convert the price of the bonds will increase significantly and track the token.

Once a gnosis auction is started there is no way to cancel the ongoing auction. We theoretically still would be able to modify the collateral backing the bond or the convertibility ratio though...

Do we know what the expected user flow is? I would guess that no matter what bondholders would probably advertise the auction ahead of time. Additionally this would likely be a topic on their governance forum no? Could the governance form be used as the intent to issue a bond?

How long do bond-purchasers need to do due diligence on the bonds?

Borrowers have the option to limit access to their auction through whitelisting and setting a minimum bid size.

From https://app.gitbook.com/o/aqu26msxcMEfPPcwEPfW/s/ERPLSn9guer0VI2MxqZ6/protocol/borrowers/how-to-issue-bonds

We need to figure out how this functionality will fit into our product

After releasing Porter Convert, we'd like to release a refinancing product. This product would allow users to repay old bond issuances with a new bond issuance. The following process would take place:

1. Investor buys new bond
2. Money is used to pay off old bond collateral
3. Old bond collateral is transferred to the new bond vault
4. New bonds are minted against collateral and given to investor.

Therefore, an issuer would need to allow our refinance contract to repay the bond and withdraw their collateral. We should add a feature that allows issuers to grant and revoke repayment + withdraw collateral access. We need to add this feature before our audit.

https://github.com/gnosis/ido-contracts#audit

Good to understand and see the flaws they accidentally introduced since we are using those contracts.

Read https://docs.google.com/document/d/1RvlA-J_D-p-mwrcaHaZrbleguUhPlio2kX2eWAqr5oc/edit

Skip section 6 for your first passthrough, and read it after you have read everything else

When an issuer repays back a partial amount of borrow token and the bond defaults, give the bond holders a portion of that token in addition to the collateral.

Question: Should the issuer instead be able to withdraw the deposited borrow amount?

Figure out how to store maturity date and how we'd be able to check if the bond has matured

contract Bond {
maturityDate: type? 

function checkIfBondIsMatured () {
logic? 
}

}

In current implementation of the current product spec there is a field for prospectus.

This may no longer be necessary since bonds are now overcollaterlized. Check with Jordan if its still in product spec after it gets updated on March 2nd

• Learn about https://thegraph.com/en/
• Figure out how exactly we can use this in our protocol - I'm thinking that we create a subgraph then query the subgraph to get the information needed on each of our product screens: https://github.com/porter-finance/product/tree/main/spec/pages
• Note down what data we'd need to expose from our smart contracts for the subgraph to enable our frontend
• Made a subgraph repo (public)
• What would the costs of using the Graph be?
• Estimate level of work to build out the full subgraph
• Any better alternatives?

There are a lot of examples of subgraphs.

• https://github.com/Uniswap/v2-subgraph
• https://github.com/aave/protocol-v2-subgraph
• https://github.com/compound-finance/compound-v2-subgraph

Overview

When a new bond is created - we can mint a NFT and send it to the issuer of the bond.

This NFT would serve two primary purposes:

1. Access control: Only the owner of the NFT would be allow to interact with specific methods on the bond, like withdrawing collateral. Ownership transfer is as simple as transferring the NFT.
2. Asset Representation: This would give borrowing an asset that represents their borrowing position. Thier borrowing position would be viewable in etherscan and in defi aggregators.

Technical

The current implementation relies on the issuer address being passed in at the creation of the bond. There is no current way to update the issuer. It would possible to add that logic into the contract

Using NFTs would simplify transferability - as transferring the issuer is just transferring the NFT

The Broker contract would follow ERC721 and would be responsible for minting an NFT during the bond issuance.

Misc

Jelly.fi does something similar

Once a lender chooses a borrower, an NFT is generated on-chain that represents the parameters of the agreement. Each NFT comes with unique artwork. In addition, the NFT displays essential information about the agreement between the borrower and lender that can be viewed on-chain at any time. Each position can be sold to another person.

Further Research

@RusseII to watch https://www.youtube.com/watch?v=VgsODQMGI2M
@RusseII to explore what the NFT implementation would look like

Questions

@Pet3ris is there anything I'm missing here?

Meeting with peteris tomorrow - will fill this out with more information.
https://github.com/balancer-labs/balancer-v2-monorepo/blob/master/pkg/pool-weighted/contracts/WeightedPool.sol

The bond has different states in which different actors can perform different actions. What are all of those actors/actions/reactions?

Think about depositing collateral in a protocol like yearn to earn yield on the idle capital.

Current info about bondtoken here - #1

It may help if we start with the simplest design - no factories - no convertibility - no upgradability -imagine we want to create just a simple bond token.

1. The state of the bond needs to be managed.

• What is the interest?
• When is the payment due?
• How much is owed?
• What is the current state of the bond? (good standing, defaulted)

2. The borrowing party needs a way to pay back the bond
3. The lending parties need a way to redeem their bonds for interest + principle at maturity (edited)

The auctions should be permissioned at first. Only whitelisted addresses should be able to issue bonds but eventually we should make this permissionless using a verified/unverified model

AC:

• Add allow list - probably using https://docs.openzeppelin.com/contracts/4.x/access-control
• Have admin ability to remove the access control