Broker pattern or token pattern?

[RusseII]

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 Research clone factory to deploy erc20 bond contracts #15

[RusseII]

Token Pattern

Described here: https://github.com/porter-finance/v1-core/blob/e3d87a0636fb81fbbe8cdd1100ecd15b714f1305/spec/overview.md

Broker Pattern

Described here: https://github.com/porter-finance/v1-core/blob/main/spec/overview.md

[Pet3ris]

I think either can work just fine but broker pattern may is where things are going.

See https://docs.balancer.fi/products/the-vault for some of the benefits. It will allow you to have different custom types of bond contracts in the future. You will be able to support claims across multiple bonds, etc. in the future. It will also simplify your dapp - easier to pull stats like total collateral from your broker contract.

[RusseII]

I'm currently leaning towards following the token pattern

Previously, the main argument for following broker pattern over token pattern was due to a 10x increase in gas if the logic was on the BondTokens. If we are using clone factories I believe this is not a concern.

I'm a fan of the token pattern mostly because I think that it is easier to understand for new users of the protocol.

@Pet3ris is this the type of decision where you think we should continue to ponder, or just commit to one and move on?

Some differences I'm having trouble quantifying between the two patterns:

• Difference on how we'd be querying the data
• Upgradability pros and cons of each method
• Security implications of each pattern - does one of them leave more risk for a hack or larger amount of funds lost?
• Interoperability with future protocol upgrades

[RusseII]

After talking more with Peteris - Let's go with the token pattern proposed in #46. Both patterns are valid and we can refactor in the future if we need too.

Token pattern chosen mostly because it's more intuitive to users.

[RusseII]

closed by #46