Delegation and MakerDAO

For those that don’t know me, my name is LongForWisdom, and I’m one of the Governance Facilitators at MakerDAO. Today, I’m more formally introducing how delegation will operate within MakerDAO.

For those with limited time, I’ve started with an executive summary.

Executive Summary

  • Delegation is important to reduce the collective cost of governance and increase the effectiveness and efficiency of the governance process.
  • MakerDAO will have two varieties of delegates.
    • Recognised Delegates are whitelisted, and must meet certain requirements in exchange for more visibility and prestige.
    • Shadow Delegates are permissionless, with no requirements or responsibilities beyond that which they have agreed directly with those who delegate to them.
  • Recognised Delegates act as a bridge between vote outcomes and other actors by actively and transparently communicating with the MakerDAO community.
  • Delegation in Maker will soft launch on August 2nd, 2021. Hard launch will be accompanied by a community marketing push and will occur once additional criteria are met. These criteria are outlined toward the end of the post.
  • Delegation will launch with multiple delegates drawn from active members of the MakerDAO community for MKR holders to choose from.
  • MKR holders will continue to be able to vote on proposals directly if they do not wish to delegate their tokens.

Why is Delegation Important?

Delegation brings many advantages. I’ll highlight some of the most important benefits of delegation here.

Token Participation

Recently, it’s been harder to ensure that there are sufficient MKR tokens within the Maker governance contract in comparison to the MKR tokens accessible within the rest of DeFi.

This has implications for governance security; to keep the Maker protocol secure, attackers should not be able to borrow more MKR than is present on the current executive proposal.

Delegation gives us a low-cost method to involve currently idle MKR tokens in the governance process, which may help to mitigate the issues that arise from a lack of vote-weight participation.

Reduces the Collective Cost of Governance

By virtue of allowing users to pool their MKR we reduce the collective cost of governance that MKR holders (some more than others!) currently bear. This is true in two ways:

  1. Fewer individual wallets voting for the same vote-weight means less gas is paid per voting token per vote.
  2. Fewer individuals need to actively track and keep up with governance of the Maker Protocol which results in less human-hours spent per voting token per vote.

Critically, delegation allows us to reduce these costs without significantly reducing the effectiveness of decision making.

Improved Efficiency and Direction

Finally, delegation helps to reduce the communication and direction issues that arise in the governance of a large, decentralized protocol. Having known delegates with a known vote-weight means Core Units will be able to much more effectively coordinate with governance to achieve goals - both long-term and short-term.

This should help to streamline operations and allow MakerDAO to respond more effectively to the ever-changing landscape of DeFi.

Two Types of Delegate

Unlike other implementations of delegation in the ecosystem, the Governance Facilitators of MakerDAO have introduced a distinct split between two types of delegate. These two types of delegate are known as Recognised Delegates and Shadow Delegates.

This split is being implemented for a number of reasons.

First, it’s become fairly clear from other implementations of vote delegation that it is not guaranteed to result in an improvement to the governance process of a given protocol. In some cases, it has resulted in less transparency and more contention around governance decisions.

Second, delegate quality has been extremely inconsistent in the wider ecosystem. One can argue that the market will resolve this issue and good delegates will receive more voting power, however the market is not perfectly efficient and the existence of a very small number of quality delegates will introduce further centralization of control of the given protocol.

It is important to note that the delegation contract itself is entirely permissionless. Delegation within the Maker Protocol is not whitelisted, rather an additional status as ‘Recognised Delegate’ is whitelisted, and comes with certain responsibilities and advantages.

Recognised Delegates

Recognised Delegates are our attempt to resolve some of the issues above. Recognised Delegates must adhere to a list of requirements managed by the Governance Facilitators of MakerDAO. In exchange for adhering to these requirements, they are integrated directly into the official voting interface, discourse forum, and chat platform and highlighted to MKR holders that may want to delegate.

Note that Recognised Delegates can be pseudonymous (but not anonymous), so long as they meet the requirements below. These requirements are not a terribly high bar, and consist of the following:

  • Sharing contact details
  • Publishing a delegate platform post.
  • Appearing on a live call to speak to MKR holders and community members to answer questions about their platform.
  • Publicly agreeing to follow a Code of Conduct.

In addition, the Governance Facilitators will track participation and communication metrics for each recognised delegate.These metrics will be displayed on the official voting UI, resulting in a soft requirement for Recognised Delegates to participate in as many votes as possible, and communicate their reasons for voting to the MakerDAO community.

These requirements and metrics may be adjusted in the future depending on the number of Recognised Delegates, the resources available to the Governance Facilitators, and feedback from the delegates themselves.

Shadow Delegates

Shadow Delegates are the natural consequence of having Recognised Delegates and a permissionless delegation smart contract. Any delegate that is not a Recognised Delegate is defined as a Shadow Delegate.

That said, there are several advantages to having Shadow Delegates in addition to recognised delegates.

  1. Shadow Delegates can be publicly anonymous (note that anonymous is different from pseudonymous.) This gives them an additional layer of defence against real-world interference.
  2. Shadow Delegates can make private arrangements with individual MKR holders.
  3. Shadow delegation can be used ‘in-house’ by larger MKR holders to manage voting with custodied assets.

Delegation Timeline and Soft Launch

Contracts

The mainnet and Kovan delegation contract factories are already live on-chain.

Kovan Deploy: 0x1740F3bD55b1900C816A0071F8972C201566e3a3
Mainnet Deploy: 0xD897F108670903D1d6070fcf818f9db3615AF272

Anyone can use the factory contract to create a delegate contract or integrate with delegation in Maker. Note that you only need to interact with this factory contract if you want to become a delegate, not if you want to delegate your MKR to a delegate.

Audits

The delegation contracts have been audited by ABDK. The audit report from ABDK can be found here. No major issues were found and minor issues have been addressed where appropriate.

User Interface

The MVP delegation UI will launch on August 2nd (soft launch), and will include:

  • A list of Recognised Delegates with avatar, name, and links to their platform.
  • MKR Delegated to each delegate (in total and by the connected wallet.)
  • Participation Metrics (Poll & Executive)
  • A list of Shadow Delegates.
  • Delegate + Undelegate user flows.
  • A Create delegate contract user flow.

Initial Delegates

Several community members have volunteered to be Recognised Delegates at the launch of delegation. Platforms for some of these delegates are publicly available within the MakerDAO official forum and more will follow over the next few weeks.

‘Meet Your Delegate’ meetings will be organised in the weeks leading up to the launch of the MVP UI, and will be a chance for MKR holders - large and small - to meet the initial set of delegates and ask any questions they may have.

Hard Launch

Hard launch of delegation will take place once the following criteria are met, and will be accompanied by a marketing push from the community with the goal of attracting additional MKR holders to delegate their MKR.

Hard Launch Criteria

  • Integration of delegation with leading custody providers, allowing larger MKR holders to delegate securely.
  • V1 of the Maker delegation UI, including Recognised Delegate profiles.
  • Multiple Recognised Delegates active and engaging with the Maker community.

Want to participate?

If you’re interested in being a Recognised Delegate, the list of requirements (including contact details) can be found here. Feel free to get in touch.

Our first ‘Meet Your Delegate’ meeting is scheduled for July 28th - 18:00 UTC. Join us and ask our first few delegates about their vision of MakerDAO’s future. Check out the agenda here.

40 Likes

Really excited for this, thanks for the hard work. I have one piece of feedback.

While I’m not opposed to the concept, I’d like to see “recognized delegates” encoded into a MIP and voted on. Also wouldn’t it make more sense to put the recognized delegates list in the hands of MKR holders themselves? They could maintain a list similar to the one I’ve outlined in MIP57.

4 Likes

So I feel like there are two main points here.

  1. Why not make this a MIP?

Mainly because everything discussed in the post is something any individual could start to do without the consent of the Maker community or the Maker Protocol. Any random person could setup a voting platform, deploy a delegation factory and start highlighting certain delegates as recommended / recognised / etc.

There are no permissions required to make this work, so why would MKR Holders vote to allow or deny something they have no control over? They might vote to condemn it or endorse it, but that’s not required for it to operate, and doesn’t need to be done in advance.

In the future though, there will likely be MIPs defining Recognised Delegates more strictly, because there will be things that require MKR Holders signoff. The most obvious of these is paying delegates - MKR Holders would need to sign-off on any funding delegates received, therefore it becomes important to define what class of delegate is eligible for funding and why (and confirm that MKR Holders want to fund delegates.) Another example is if the protocol wishes to delegate any explicit powers to recognised delegates - hypothetically, if the protocol controls some Aave you might want to let the delegates vote with it using a multi-sig rather than forcing an executive vote.

Delegates by definition are in the hands of MKR Holders, a Recognised Delegate with no MKR delegated to them is more or less the same as an active community member. At this stage there are no concrete benefits to being a recognised delegate beyond being more visible to MKR Holders.

  1. Why not elect recognised delegates as part of a MIP? (I think this is what you’re asking, please correct me if I’m wrong).

Power is already given to delegates by MKR Holders. A Recognised Delegate with no MKR delegated to them has no power and non-zero responsibilities. So, no, I don’t think it makes sense to elect Recognised Delegates directly because they don’t have any power until delegated to.

Once there are specific powers that come from being a recognised delegate, or benefits bestowed by the protocol, then the requirements will need to be more formally defined, but even then electing them as part of a MIP is pointless when they are elected by MKR Holders delegating to them. You can just make a requirement a minimum amount of MKR delegated.


This is off-topic, and we can take it to the other thread, but I don’t actually believe the list in MIP57 makes sense either - for the same reasons. The MIP bestows no power on the members that is not already a power that everyone possesses (the ability to advise the DAO.) So MKR Holders would be voting to give / deny something to a group that the group already possesses and that the DAO cannot take from them.

11 Likes

I want to second all the points that @LongForWisdom is making here. I think they are incredibly important if we want to have any chance at scaling the DAO.

My own interpretation (and this may be much stronger than what LFW is stating):

  • MIPs should not be used as a Q&A with MKR holders to surface their opinion. We can have MKR polls for that outside of the expensive (in terms of bandwidth and energy) MIPs framework.

  • MIPs should be used every time where we, as a community, need to agree on the usage basically of public goods. When you simply cannot move forward without asking for permission first.

In general, if something can be done without a MIP, do it without a MIP.

MIPs are a centralization bottleneck in terms of dependencies (asking permission not forgiveness) in an otherwise decentralized environment. While they are a critical building block (1) to agree on the allocation of limited resources, and (2) to enforce security guardrails that avoid critical failure of the protocol, their scope should be limited as much as possible.

The only way a DAO can compete with a centralized organization at scale, is to unlock parallel work that is not blocked, whenever possible, by waiting for a slow consensus process. By trying to express every MKR holder’s wish into a MIP, we are killing our competitiveness. This is not how we should engage with MKR holders and it’s not what MIPs should be used for.

Delegation, hopefully, will create another opportunity to engage with MKR holders more directly.

8 Likes

@LongForWisdom @wouter I think you’re both making very good points, but I respectfully disagree. I believe you’re conflating “decision minimization” (a phrase I’ll use in lieu of governance minimization as it has more specificity) with “decision deferral,” which I’ll define as the implicit deferral of decisions to another group. The first is a philosophy that I personally ascribe to and believe we all mutually agree upon, the latter seems to be a core difference between our opinions - one which I hope to convince you both to amend.

Firstly, there’s an inherent contradiction in this argument:

On one hand you’re saying that this is “permissionless,” but in reality it’s a task that can only be performed by a governance facilitator. So I ask, where in the Governance Core Unit’s mandate does this power appear to be vested? The only item I see in the Governance Core Unit mandate relating to frontend control is the following:

  • GovAlpha is responsible for creating on-chain polls on the ‘official’ voting frontend as directed by governance processes defined in relevant Accepted MIPs or MIP sets.

With your own admission, the frontend the Governance Core Unit has technical administrative rights over has an “official” character to it. Where did it receive this designation? Surely it is from the MKR holders themselves that lent the frontend this “official” legitimacy. If we can agree on that, then should the assumption not be that MKR holders have conceptual control over the frontends until they otherwise delegate such responsibilities? The delegation of some administrative rights does not presume the delegation of all administrative rights. If governance facilitators were to have blanket rights to manage the frontends as they see fit, why make the distinction in your mandate to follow the “governance processes defined in relevant Accepted MIPs or MIP sets”? In this context, I think it becomes clear that there is a decision deferral being made here, not decision minimization. If this is a deferral you would like to see be made officially, there should be a MIP awarding you this power.

A Recognised Delegate with no MKR delegated to them has no power and non-zero responsibilities. So, no, I don’t think it makes sense to elect Recognised Delegates directly because they don’t have any power until delegated to.

Again there is a contradiction. This would be a valid argument if delegates were not being “elected” (although perhaps this is not the right word) in the first place, but they are being elected… by the Governance Core Unit. It’s not the absence of an election, it’s the delegation of the election process to the Governance Core Unit. You may argue that you are simply enforcing rules to be followed and that you only maintain a veto over who may be “elected,” but this is an identical process that could be followed by MKR holders without deferring the veto rights to the Governance Core Unit.

  • MIPs should be used every time where we, as a community, need to agree on the usage basically of public goods. When you simply cannot move forward without asking for permission first.

While they are a critical building block (1) to agree on the allocation of limited resources…

Legitimacy is the currency of governance, and all legitimacy (and sovereignty) must remain with the MKR holders unless explicitly released via a MIP. This legitimacy is the greatest public good we have and it is our scarcest resource. Without trust in the authority of the MKR holders, every incentive and construct in the system that ensures the stability of Dai is worthless.

I think we need to delineate between “can” and should." Just because something is possible to do outside of the MIP process, does not mean that it should be done or tolerated. This is deferral, not minimization. To use an extreme example: It is possible for LFW to simply say “I’m not going to include this otherwise valid MIP on any voting frontend that I control.” While he “can” do this in the most literal sense of the word, I think we all agree that he shouldn’t. But with “shouldn’t” there needs to be enforcement and a culture of intolerance, or else it remains a deferred decision/power. So my question is this: if the collective governance facilitators were to refuse to put an otherwise valid MIP through to a vote on the “official” frontend, would this not be a clear violation of mandate? If it is a violation of mandate, should the offending governance facilitators not be immediately removed as a matter of principle? This example is extreme, but I think the answer to that question hits to the crux of my argument - it needs to be clear where the legitimacy and sovereignty lies in this system and it does not lie with core units.

The only way a DAO can compete with a centralized organization at scale, is to unlock parallel work that is not blocked, whenever possible, by waiting for a slow consensus process.

There is nothing about “recognized delegates” that limits the ability for the community to perform work in paralell. In fact, it could have the opposite effect by bestowing legitimacy onto a smaller number of people who can then attempt to capture more legitimacy at the expense of “shadow delegates” (even the name has a negative connotation) and counterproductively inhibit paralell processing through capture of the frontends.

On the contrary, the only way to compete with a centralized organization is to not become one. Decision deferral is a centralizing force - the efficiency gains are not worth the price. These small but incremental advances of power to core units are counter to the goals that we all wish to achieve.

3 Likes

Aight. First of all lets try to keep terminology correct, because ‘deferral’ doesn’t have the meaning you’re ascribing to it here. The correct word would be ‘decision delegation’ though admittedly that’s confusing in this context. Deferral more explicitly means postponement of something (a decision) through time.

Incorrect, anyone could set up to do this with their own frontend.

However, regarding GovAlpha’s mandate, we’re supposed to be facilitating governance processes. This is a facilitation (tracking delegate performance) of a governance process (delegated voting).

No, it’s legitimacy is historic. It’s the oldest, the Foundation set it up, etc.

No, I don’t agree to this. Every front-end is ultimately controlled by whomever is running the frontend. MKR Holders have some influence over a front-end that the protocol is funding.

We don’t have blanket rights to manage all the frontends, we’re not even managing the frontend directly in this case. We have described a structure for delegation in Maker, dUX are implementing it in the frontend. If a different frontend wanted to ignore us, they could. dUX could ignore us, if they wanted to. In practice, dUX presumably feels that GovAlpha has a mandate to make these sorts of decisions, though I doubt they reasoned about it explicitly.

Yes, I would agree with this point. And I consider the deferral (delegation) of the power (such as it is) to facilitate governance processes to be implicit (if not explicit) in the GovAlpha mandate. Part of the point of having Governance Facilitators is that they can make calls when things are not officially stated anywhere. No where is it stated who is responsible (or not) for delegation. It fits to GovAlpha better than it fits anywhere else, so we did it.

No, they really aren’t. Every definition of ‘elect’ references one entity or collective choosing another entity or collective. What we’re doing is setting up a framework which represents a if-then relationship of responsibilities to status which is enforceable via cooperation of the group that actually controls the frontend (which is dUX, I guess) . IF a delegate fulfils the requirements to be a Recognised Delegate (and wants to be so) THEN they are classified as a Recognised Delegate which is reflected on cooperating front-ends.

There is no wiggle room here, it’s not us saying ‘hey we’re going to pick random people and promote them’ it’s us saying ‘These are the requirements that you need to meet to get this status. Meet the requirements to get the status.’

Like, compare this to a foot-race or a game show or something. IF you finish the race prior to the other competitors, THEN you get first prize. You don’t say that the race organizers have elected the race winner. IF you follow the rules and win the game show THEN you get the prize. You don’t say the game show organizers elected the winner.

We’re not even maintaining a veto here… at least, we hadn’t mentioned one. In practice the requirements may change dependent on how many recognised delegates there are, how onerous the responsibilities are, how much bandwidth we have to manage the process. If the requirements do change, all delegates will still be subject to the same requirements.

Please explain to me what authority we have removed from MKR Holders here. They can still delegate to whomever they want. They can use a different front end. Hell they don’t need to use a front end at all.

Front-ends and Delegates are conveniences that make it easier for MKR Holders to exercise their authority. If we were attempting to ban all other front-ends, ban other delegation contracts, ban any engagement outside of this process. Then sure, that’s impinging on the authority of MKR Holders (although again, it actually isn’t, because MKR Holders maintain full control over the Maker protocol via executive votes - MKR Holders can opt out of the entire governance process - even the entire DAO - if they want to).

The choice of a name with negative connotations is an intentional choice. MKR Holders should think really, really carefully before they delegate to a shadow delegate when they have no idea of their incentive alignments or their identity. Shadow delegates can have absolutely no incentive alignment to the Maker Protocol. I will cover this more in a future post, but delegating to an entity with no alignment is hugely dangerous, and should not be done unless MKR Holders have a personal relationship or trust in the individual shadow delegate.

This is the problem that Recognised Delegates help to solve. For those MKR Holders that have no connections to shadow delegates, and no idea who to delegate their MKR to, it offers a set of choices that is safer than picking someone out of a hat. Recognised Delegates are more safe because at the very least, they have reputational capital on the line. In the future they may also have an income stream from the protocol that would also be on the line.

5 Likes

There are many points here that are worth discussing, but maybe we should move it to a different thread to avoid going offtopic and allow the discussion a longer lifespan.

Always open to changing my point of view, but as it stands I’m seeing things very differently. I’ll select just this one quote to illustrate and I’m happy to have a longer discussion later.

This, to me, is centralized thinking. I may need to look for better phrasing to explain this, but in a way, you’re implying that “legitimacy” or, acting in the name of the DAO in an official capacity, is handed down from MKR holders to core units. Which implies that MKR holders are dictating the actions of the core units in a command and control structure, a hierarchy, with all the ensuing implications.

The way I see it, maybe with a few exceptions (-- trusts?), this is not the case. MKR holders allocate funds. They sponsor, they subsidize behavior that they want to reward. It’s the core units that do what they do, and seek sponsorship for it through governance. They are essentially independent, in control of their own strategy, roadmap, and so on.

Much like a government would subsidize an art exhibition. The subsidy may come under certain conditions, but it would not be right to say that the exhibition is mandated, or controlled, or legitimized, or even endorsed outside of the strict conditions of the subsidy, by the government. The subsidy may be to encourage accessibility for people with a disability, or eco-friendly construction methods. The art exhibition is still independent, they just conduct an activity that the government, for some reason, wants to encourage.

Nor would that government be held responsible for any misconduct by the exhibition’s organizers as opposed to, say, a government agency that would show misconduct, in which case this government would be responsible, potentially even liable. (The government may still be held morally responsible for sponsoring an unsound organization, but this has more to do with the responsibility that this government has towards its electorate, while MKR holders don’t have an electorate.)

Similarly, MKR holders may choose to retract funding when they no longer believe that a core unit is doing something that is worth funding from the DAO’s pov. And delegates may organize the dialog between MKR holders and CUs by clarifying the conditions for the subsidy or providing relevant feedback.

Somewhat goofier but maybe a better analogy: the DAO funds CUs like a gardener waters trees. The gardener wants the fruits from those trees and is clearly watering them for that purpose. But the gardener can never choose to grow lemons on an apricot tree. The tree is clearly in control.

In your model, control is handed top-down the hierarchy. In my model, bottom-up behavior is either encouraged or discouraged.

You can’t do that, @g_dip

Now, the final complication is the question whether, next to these subsidized independent core units, the DAO should also have the equivalent of a government administration or government agencies, that are indeed restricted by a very narrow set of instructions. I believe it might, although hopefully only on a minimal level. And it so happens that GovAlpha might be the closest to this case, and enabling delegate voting might fall under its responsibilities.

So… in this particular case I might still be persuaded in either direction. I do consider it one of the cases in the grey zone. My previous post argued under the assumption of the (relatively) independent core unit.

// Edit:

I wrote my post simultaneously with @LongForWisdom but I believe we’re largely aligned here.

And here I was thinking that it was my non-native English that must have been the issue D:

This is a very problematic term, in my opinion. It should never have been called mandate, because a mandate does imply that one is acting in the official capacity of the DAO. This can (almost?) never be the case: one can be sponsored / subsidized by the DAO, or not sponsored / subsidized by the DAO. And that’s about it.

1 Like

Perhaps it’s an Americanism, but we say this all of the time…

Yet you refer to this frontend as the “official” frontend. Can you address this disconnect? How can another frontend gain this “official” designation?

Well by that logic, the Foundation was given its legitimacy from the MKR holders when they voted on this. So do we now agree that the frontend is only “official” because MKR holders have awarded it that designation?

Then this is what I challenge. I do not believe that Core Units have implied powers. All power must rest with the MKR holders unless explicitly vested elsewhere.

I used your word and even pointed out I didn’t think it was the right word, so I agree they are not really being “elected.” That doesn’t address my point that there’s no reason for the Governance Core Unit to be in charge of this process rather than providing MKR holders with an explicit veto right or control over the requirements (the exact powers you are assuming the Governance Core Unit is vested with).

Controlling the requirements is the problem. Like I said, if you were putting the requirements into a MIP and then requesting that the MKR holders vest you with the power to enforce them, I’m fine with that. I’m not fine with the Governance Core Unit controlling who can and can’t be a Recognized Delegate by altering the requirements to whatever they see fit.

Again, I’m not arguing with the concept. I am arguing with the idea that the MKR holders should not control the process.

Since most of your other points address frontend control and legitimacy, I would like you to answer the question I posed in the initial post:

For the record, I do consequently believe we should indeed not talk about “the official front-end.” When I wrote elsewhere that our language still reflects centralized thinking all the time, this is an example of what I mean.

5 Likes

I want to address your reply as well, by the way. You raise some really great points (so does @LongForWisdom )…just need a bit of time to go through it :slight_smile:

2 Likes

Looking forward to it, comrade Di Prisco.

6 Likes

You know my answer is yes to this. The same would be true if we start arbitrarily changing the Recognised Delegate requirements with the goal of excluding specific people for some personal gain as opposed to changing them for reasons of functionality. Note that the delegates themselves are a great check on power here, as if they become no-longer eligible they still have MKR delegated to them to throw up dispute resolution SP’s or offboard me.

I do not agree that doing things beyond what is explicitly in the mandate counts as violation of that mandate. I think that’s a fantastic way of getting facilitators and core units that don’t do anything. Sounds like a great way to kill initiative and encourage malicious compliance.

Sounds like this might be a good way to test out MIP52 though, if you still object and feel like I’ve exceeded some boundaries here.

4 Likes

These are good counters. I don’t think it’s applicable for MIP52 because I could just make a MIP to the affirmative, but you’ve provided some food for thought on whether that’s the right direction.

5 Likes

Thank you for bringing up your concerns, Greg. I responded more hastily than I should have yesterday. With a clearer head I don’t believe that my position on this has really changed, but I should have responded more respectfully.

I really do appreciate your point of view, and I did read your post on legitimacy, though I never got around to responding. I can’t say I align with all of it, but it felt valuable to read and there are definitely parts I agree with.

It’s almost inevitable that we’ll end up with a set of MIPs covering delegation eventually. So I’m hoping in the long run we’ll get to a state that everyone can accept. Thanks again.

6 Likes

There’s no hard feelings whatsoever. For what it’s worth I didn’t detect any disrespect in your replies. I thought it was good, enjoyable discourse :slight_smile:

3 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.