[DAO Discussion] Transition WL Tech and Add Team Member

Dani and our technical team have decided to step back from Wonderland. Four important items contained in this proposal will assist in a smooth transition.

  1. Allow Alice to make changes to the Team which incur no additional cost to the DAO.
  2. Provide authorization and access to improve, troubleshoot, or otherwise make changes to all official Wonderland tech and documentation.
  3. Payments for additional dev work, if required, will get authorized by the multisig without a DAO vote.
  4. Catalyst, a longtime community member who helps with server bots, security, and runs the Wonderland tracking website frogs.army, is joining the Team to assist here.

The current elected Team will share the cost burden to compensate the added member.

Payments for any contracted work are expected to be within industry competitive range and shall not exceed $10k per month. If further funds are needed a proposal will be put forth.


Some helpful tweaks to our operating procedure in here! Also, we’d like to officially welcome Catalyst to the team!


I feel that this is important so that the elected Wonderland team can authorize someone qualified and trustworthy from the community the oversee the technical responsibilities involved in maintaining our website/dapp. As Wonderland goes through this transition it will be more important than ever to include someone with the technical expertise on our team.


The verbiage in points 1 thru 4 isn’t specific as to added team members role but in your comments it makes it sound like overseeing website n dapp are key roles being delegated to catalyst. I’d think specifying it in dao discussion points is important so people get what void is being filled out of necessity.


That’s because the added member isn’t being paid for the type of work they will help out with. A proposal to increase budget due to the team now managing the operation may come through. For now we want to keep things simple for a smooth transition.

My initial thought was to leave off point 4, because point 1 effectively allows for point 4 to happen without governance. Point 4 (adding Catalyst) was included to show we have someone capable that will cover delegation of tech work as needed.


Ok but there’s no mention of the specifics. Like we are bringing on catalyst as he has experience in app dev, source control etc to ensure smooth transition of tech stack, website and source control to the dao. I realize it’s not paid but I think since clearly that seems to be ultimate plan why not provide a few more details. Also payments for additional dev work is a bit vague as many things including transition tasks could involve dev type work. Maybe you planned on adding details as it moves further along but we do need to avoid ambiguities in order to get support and confidence in the process. Imo given the events I feel it’s important to be as transparent and informative as possible.


For Catalyst, It is paid, we just aren’t increasing the mod pay asking amount to cover the addition. We’re all taking a pay cut to accommodate his pay. The nature of this proposal is to give Alice the authority to make the judgement calls to make the changes to the team that are needed without a 2-3 week governance proposal each time, as team lead, this is discretion that she needs in that position. Lastly, the dev work is meant to be somewhat broad in scope. We need to be able to pivot quickly on some development issues, again without waiting for 2-3 weeks of governance. The big DAO-level decisions will go through governance, but this will allow us to not drag our feet for half the year before any moves can be made. If an emergency pops up that requires a dev, or a quick opportunity where something needs to be developed (web work, smart contract fixes, etc etc), it can be done with little friction. These types of things you don’t generally know are coming before hand, and require fast movement.


On point 1 below besides catalyst are other changes expected and if so please elaborate on those.

  1. Allow Alice to make changes to the Team which incur no additional cost to the DAO.

Took your notes from above and will add to RFC.

On this point, no other changes are expected.


Its slightly unrelated but, does wonderland get other programmers to audit code before it’s deployed. E.g redemption contract modification for the most recent redemption was built in a day.

Another point is, there’s always going to be some advantage to being in the loop vis a vis the coding process – e.g there was someone who redeemed within seconds of the redemption contract going live, and they very likely had knowledge of the merkle root of the redemption smart contract before it went live, allowing them to redeem first and dump BSGG at the best price.

No hate on them, they acted based on their incentives – but is there any measure that can be introduced in this proposal to prevent such a conflict of interest between people involved in developing for wonderland?


I support these proposals.


We plan to have everything audited, yes.

Alternative - and to your second point - would be a redemption similar to SV, without smart contract risk and airdropping any tokens such as bsgg to the wallets.


Catalyst joining the team is long overdue, i support this prop


After putting more thought on this, points 1 and 4 seems redundant if the goal is to just add Catalyst. Point 1 gives some extra room to do things without DAO approval and I guess I should ask what kind of timely notification would be given to the DAO for any changes with explanation?


They are. However, I think point 4 can serve as that notice you mention.

1 Like

In my opinion it is a great step for Wonderland to function as it should and grow accordingly, although the price may seem somewhat excessive to me, I understand that the experience and good work of a professional and experienced team has a price, being a field that I am completely unaware of, I cannot give an in-depth opinion on the matter, but I would like to emphasize that I agree and that I wish it to be a great step for the entire DAO


Point 4 only works for this time. What about Point 1 being utilized in the future once permission is given?
If Point 1 is used later what should people expect for visibility and notification to the DAO ?


As per [WIP #6], Alice has the discretion to allocation funds according to team members performance and monitoring moderators work to maintain accountability.

  • Technically, in the event of a disciplinary offense by a moderator, a long inactivity period, great performance concerns or for any other serious reason, Alice can dock a moderator’s allocation to zero and this moderator can be considered as, unofficially, fired.
  • In the same time the Team can technically hire somebody, unofficially, as they did with me, when there is a need of expertise in a specific field of work and call it donations out of pocket.

Currently, there are limitations and problems with the team management which are important to solve to ensure the Team is properly functioning at the best way possible to provide the best experience for the users and token holders and general improvement for the protocol. With this proposal we hope to solve these issues and to move forward with utmost transparency.

The budget won’t alter for any personnel changes, no extra cost for the DAO.
If more funds are required there will always be a new proposal, for the DAO to decide and execute.

The main reason for point 1 of this proposal is to ensure visibility and transparency under any conditions.
There will always be notification, for any non-minor changes or adjustments.


This makes sense. The only thing is that there is nothing in This that states notification will be given and time frame for notification of changes made. So while the implied intent might be to notify the dao there’s nothing I see that ensures that will happen. it isn’t specified in the details of this proposal so what guarantees the notification and on what time frame? I think it’s important that something be stated about that if visibility and transparency are to be ensured.


I agree, it should be mentioned moving forward with the RFC.