Diagram Drawings as requested

[SeaSaltyFunk]

Includes diagrams of oSUSHI proposal thread comments as detailed here provided at request of @ControlCplusControlV

[ControlCplusControlV]

Reading through now, I really like the ability to allow a perpetual lock switch which keeps someone at max voting power until switched off before decay (and exit countdown) begin.

The idea of OLM is very interesting, because the reward token problem does still highlight that reward tokens often end up as something for nothing with downward pressure. I will still need to think about this more but I think I am warming up to it more.

I also like the distinction this gives to Sushi over other ve tokens. I will still need to discuss it more but I think it could be a viable alternative to pure ve tokenomics

[sambacha]

These diagrams should be individual files without text, preferably in UML format or DOT notation. Keep the text associated with the digrams should be kept in markdown. All of this is great, keeping them in those format lets other people contribute easier and lets it be edited to be included in public facing docs.

Ideally the UML diagrams can be included in source comments to help aide auditing the contracts in the future.

[SeaSaltyFunk]

I also like the distinction this gives to Sushi over other ve tokens. I will still need to discuss it more but I think it could be a viable alternative to pure ve tokenomics

Cool, glad it could help get the ideas across a bit more. I realized I didn't really make a diagram to demonstrate how bought-back SUSHI can be added to the gauge controller, therefore, extending emissions runway - hopefully, that was implicit?

If it helps to discuss further, just let me know and more than happy to talk through any of this further.

[SeaSaltyFunk]

Keep the text associated with the digrams should be kept in markdown

Happy to do a copy paste of that text if it helps.

These diagrams should be individual files without text, preferably in UML format or DOT notation

This was actually my first time diagramming something like this, and have no experience in those tools but happy to save them as separate images too for someone to replicate in UML. Let me know if that helps?

[sambacha]

Keep the text associated with the digrams should be kept in markdown

Happy to do a copy paste of that text if it helps.

These diagrams should be individual files without text, preferably in UML format or DOT notation

This was actually my first time diagramming something like this, and have no experience in those tools but happy to save them as separate images too for someone to replicate in UML. Let me know if that helps?

They look great!

For UML (Really PlantUML), here are some examples:

Compound Finance just released a v3, and they actually document some of their contract design in UML so here is an example from them:

configurator_diagram

https://github.com/compound-finance/comet/blob/main/diagrams/configurator_diagram.uml

PlantUML Rendering of the configurator_diagram.uml

https://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000

tx2uml

https://github.com/naddison36/tx2uml this tool generates a UML file from a transaction

solidity2uml

https://github.com/naddison36/sol2uml generates a UML diagram from solidity source code

assorted examples

https://github.com/sambacha/tx2uml-gallery/tree/main/public/images this repo has both images and the uml files. These are all transactions that are related to exploits/hacks.

There may be a way to convert these files into an open format too but I did not find anything (i only searched for a min. or two)

[sambacha]

Just note, do not worry about getting the semantics of UML correct: these are just diagrams for visual and illustrative purposes, we are not worried about being 'correct' as it relates to UML syntax / modeling.

[ControlCplusControlV]

I also like the distinction this gives to Sushi over other ve tokens. I will still need to discuss it more but I think it could be a viable alternative to pure ve tokenomics

Cool, glad it could help get the ideas across a bit more. I realized I didn't really make a diagram to demonstrate how bought-back SUSHI can be added to the gauge controller, therefore, extending emissions runway - hopefully, that was implicit?
If it helps to discuss further, just let me know and more than happy to talk through any of this further.

Yes this was implicit, I am just looking at what this would look like from the code perspective and trying to see if there is an easy way to model the implication

[ControlCplusControlV]

@SeaSaltyFunk have you been able to see if there is a way to convert to UML?

[SeaSaltyFunk]

@ControlCplusControlV no, to be honest, I didn't even look at this since I shared original docs. I'm not 100% sure yet what parts of the suggestions are being considered for implementation so it's a little tricky to understand what would be required as UML diagrams. Feel free to drop me a note and we can chat some more if that's quicker/easiest?