CLOIP-7: Trustless Treasury model

[Dexaran]

---

cloip: 7 title: Trustless Treasury model for Callisto Network author: Dexaran (@Dexaran) dexaran@callisto.network status: Draft category: Meta created: 17 February, 2024

Treasury split proposal

On Feb 15th, Callisto Enterprise exploited the governance privileges on Treasury address and transferred all funds from the Treasury (approx. 26M CLO or $18,000) to their multisig violating Treasury funds management rules as they didn't notified @Dexaran (the founder and the second Treasury key holder) of the transaction.

In response a governance privilege of SOY token was utilized to force Callisto Enterprise to involuntarily refund the half of the funds that they withdrawn from Treasury without permission.

The funds are currently located here:

• Enterprise's multisig
• Dexaran's Treasury share

With this accident it became evident that the trust-based Treasury management model is no longer feasible. I am proposing to switch to a trustless Treasury model in the next hardfork.

Callisto Network statement regarding the Treasury accident.

I encourage Callisto Enterprise representatives to engage in a public discussion regarding my proposal in this github issue comments thread.

Proposal

• Treasury must be split in two addresses, each will receive 50% of block reward fee. Callisto Enterprise will control one of the Treasury addresses, Callisto Network backed by EthereumCommonwealth will control another Treasury address.
• SOY Liquidity providers must be refunded. I propose that Callisto Enterprise refunds their SOY users with the excess of funds that they drawn over permission. After paying the users their multisig should contain 13M CLO tokens. Callisto Enterprise will keep this tokens while Callisto Network will keep the tokens held in 0x3264Fb22a50ecadc6DFd0F0e1938a0eef965C491 address.
• Media resources management. Callisto Enterprise employee seized the twitter account of Callisto Network. Direct access to the twitter account @CallistoSupport must be granted to @Dexaran, the founder of Callisto Network. Callisto Enterprise will keep the ownership of reddit and youtube. @Dexaran will keep the ownership of telegram channels. Callisto Enterprise admins will be returned to telegram channel.
• The announcement from each party (@Dexaran and Callisto Enterprise) regarding their willingness to follow this CLOIP must be made publicly to keep the community informed.

Copyright

This CLOIP is placed under the CC0-1.0.

[creepas]

1. Step - return stolen funds and solve the soy issue you created.
2. Than we will see

[Dexaran]

1. "Stolen funds" are the funds that you have withdrawn from Treasury without my permission. You had no rights to do so.
2. Nothing will be done before you publicly describe your intentions. I don't trust you after you have withdrawn the funds from Treasury bypassing the agreements.

[theRomanMercury]

If @Dexaran's proposal is 50% - 50%, then half of the moved funds need to be sent to the Callisto Network Treasury account for the solution of the problem.

I want to add a Treasury split proposal that includes the community's share in the distribution of block reward fees (through rain) and the community's involvement in decisions.

So, it will be 33% for 3 parties. (It should also be updateable when necessary.)

Additionally, there needs to be documentation such as regulations, procedures, etc., containing detailed explanations for Treasury management.

[Dexaran]

I want to add a Treasury split proposal that includes the community's share in the distribution of block reward fees (through rain) and the community's involvement in decisions.

Could you elaborate on what "community share" should look like? Do you imagine it as a kind of DAO?

I'm not sure if we really can make it upgradeable however.

[theRomanMercury]

Firstly, the Treasury requires multiple sources of funding. Then, there needs to be a budget plan outlining how this funding will be utilized.

The audit of Treasury activities, approval of expenditures and investments should be a separate matter.

A separate DAO can be established for the Treasury, consisting of knowledgeable and elected individuals on these matters. (Committee)

The tasks of the DAO could involve evaluating proposals for Treasury management and overseeing their implementation and audit. If there is a situation where updates are not possible, then all of this needs to be thoroughly evaluated.

In a world of continuous technological and legal development and regulations, structures that cannot be updated will become ineffective.

[RrCallisto]

Hi dex, I also have proposial.

If it possible, can be smart contract using for treasury?

I suggest that smart contract internally split treasury on several parts, and rewards from each block devided between this parts.

For example, it can be three parts 1) 50% personal fund for developers 2) 25% for general purposes (i.e. servers and etc.) 3) 25% for community grants

Each part must have slightly different spending mechanism 1) personal funds split uniformly between developers and each developers don't need permission from others for using it 2) general purposes fund need confirmation from all developers maybe it can be implemented roughly this way

one developer send request for spending funds and receive some kind of id after this other developers must confirm or reject spending funds during 1 week (or another interval) if 100% developers accepted proposial (or didn't vote) transaction canbe executed

3) community grants may use similar mechanism as general purposes but also can have some limitations for example maximum spending amount can be limited but also it can be accepted faster (in 3 days for example) and require approval not all developers (50%+ for example)

Also this contract need some mechanism for adding/deleting developes I think and for adding and for deleting developer address all current developers must accept it or don't vote (during 1 month)

And of course this contract must be unchangable after deploy.

I think this kind of smart contract can resolve trust issue between developers.

[hihouhou]

how could the servers have been paid for so far if now Mr. vlad aka CALLISTONETWORK himself is helping himself to the kitty only now ? is there really such a thing as a company unable to pay for its own servers? or have they been broke from the start? How could some people let everything Callisto Network was selling as a dream go so wrong? Seriously, Vlad and all his crap (CHOAM /DC) and what we call :

• what Atanas found out about Vlad's legal problems
• Callisto's inability to pay its employees
• the lies about the employees on the website (who are no longer present or perhaps never existed)

[hihouhou]

and this guy is supposedly CEO, how can Callisto Network have any credibility with this kind of clown (just like Vlad)? how can a guy with so little legitimacy wake up so late to what's going on? divorce must be consummated with CLOE

[Upaut1]

Предлагаю адрес казначейства сделать контрактом, в котором будет разделение казны на 3 части. В конструктор контракта заложить следующие проценты:

33% казны будет раcсчитано для адреса Callisto Enterprise (может быть контрактом или EOA) 33% казны будет раcсчитано для адреса Callisto Network (может быть контрактом или EOA) 34% казны будет рассчитано для адреса контракта community (первоначально это будет мультисиговый контракт с функцией замены адреса выплат в контракте казначейства для community, на новый контракт). Адреса будут реальных членов сообщества, что давно состоят в проекте и проверены временем, а также имеют необходимые знания для проведения голосования.

Callisto Enterprise, Callisto Network, community - далее просто "получатели"

В тело контракта казначейства добавить следующие функции:

Функция которая позволяет изменять адрес выплат для каждого получателя в отдельности. Например Callisto Enterprise может изменить только свой адрес получателя на новый, но не может изменить адреса других получателей. При изменении адреса все не выведенные CLO сохраняются за новым адресом. Функция перераспределения процентов между получателями. Принимает предложение в виде новых процентов от любого из получателей, но для выполнения требует подписи всех получателей. Функция удаления получателя - требует подписей оставшихся получателей, кроме удаляемого и определенное время ожидания, например 3 месяца, если в этот период удаляемый получатель голосует против, то изменения не принимаются, в противном случае происходит перераспределение процента удаляемого получателя на оставшихся в соотношении 50/50 (либо все 100% удаляемого получателя переходят под управления community ). (Так сказать защита от ЧС). Функция создания нового получателя - можно вызывать только если получателей менее трех, во входных параметрах указывается адрес нового получателя и процент забираемый от каждого существующего получателя в пользу нового. Требует подписи всех оставшихся получателей. Функция вывода CLO - отправляет CLO только на адрес запрошенного получателя, для остальных получателей CLO фиксируется на внутреннем балансе контракта казначейства.

Думаю этих основных функций достаточно, чтобы контракт оставался максимально простым, отказоустойчивым (в случае ЧС можно обходится данными функциями, а не проводить новый хардфорк) и удобным для чтения.

Что касается контракта community, как получателя части казны, то я бы первоначально рекомендовал контракт с мультисиг, требующим более 50% подписей для выполнения любых функций данного контракта. В обязательном порядке контракт community должен работать со всеми функциями контракта казначейства, а так же иметь функцию вывода CLO на указанный адрес. До внедрения нового контракта community этого хватит чтобы платить Callisto Enterprise за сервера, ноды и т.д. Либо можно сразу предусмотреть процент выплаты Callisto Enterprise в контракте community, чтобы для каждой такой выплаты не собирать подписи.

[Dexaran]

@RrCallisto

Hi dex, I also have proposial.

If it possible, can be smart contract using for treasury?

I suggest that smart contract internally split treasury on several parts, and rewards from each block devided between this parts.

....

I read your proposal and I think it's very similar to the one proposed by @Upaut1 Let me translate it and then we can discuss the implementation of a Treasury as a smart-contract

[Dexaran]

Translation of the @Upaut1 's proposal https://github.com/EthereumCommonwealth/CLOIP/issues/7#issuecomment-1951733991

I propose to make Treasury a smart-contract that will split the rewards between three parties.

• 33% will be allocated for Callisto Enterprise address (either contract or EOA)
• 33% will be allocated for Callisto Network address (contract or EOA)
• 34% will be allocated for the community. Community funds will be governed by a smart-contract (initially this will be just a contract that can invoke "change this address to a new one" function in the Treasury smart-contract). @Upaut1 proposes that the addresses must belong to the real community members who have been members of the project for a long time and have been time-tested, and also have the necessary knowledge to conduct voting.

Callisto Enterprise, Callisto Network, Community will be called "receivers" below.

Treasury contract must implement the following functions:

• "Change my address" function. A function that allows one of the existing parties to update its address in the multisig i.e. Callisto Enterprise can update its own address without anyones permission but can't change the addresses of other parties.
• "Change payment percentages" function. This function must accept new proposed percentage distribution of the funding from any existing member of the multisig, but in order to apply the proposed percentages it must be confirmed by other existing members.
• "Remove a receiver" function. This function requires signing by the remaining receivers, except for the one being deleted, and a certain delay time, for example 3 months. If during this period the deleted recipient votes against, then the changes are not accepted, otherwise the percentage of the deleted recipient is redistributed to the remaining ones at a 50/50 ratio (or all 100% of the deleted recipients funding comes under the control of the community). (Anti-blacklist protection).
• "Add a new receiver" function. If there are less than three active receivers addresses in the Treasury contract then it is possible to add a new one with this function. In this function it must be specified how much % of the rewards are taken from any existing recipient. Requires signing by all existing parties in order to be executed.
• "Claim CLO rewards" function. Claims CLO rewards for a given receiver. Other receivers will keep their CLO at the balance of the contract stored in a local variable.

In @Upaut1 's opinion these basic functions are enough to ensure that the contract remains as simple as possible, fault-tolerant (in case of an emergency, you can deal with most of the problems with these functions rather than perform a new hard fork) and easily readable.

As for the community contract, he recommends that initially it would require >50% signing at the beginning for executing any functions. The community contract must be able to execute all the functions of the Treasury contract and an additional function to send out CLO to some "destination" address. This functions would be sufficient to enable the community contract to send out server, bootnode and other operational expenses to the Callisto Enterprise.

It is also possible to "hardcode" a share of community contracts rewards to be allocated for Callisto Enterprise to avoid voting every time the servers have to be paid.

[Dexaran]

My feedback regarding the @Upaut1 's proposal:

I propose to make Treasury a smart-contract that will split the rewards between three parties.

• 33% will be allocated for Callisto Enterprise address (either contract or EOA)
• 33% will be allocated for Callisto Network address (contract or EOA)
• 34% will be allocated for the community. Community funds will be governed by a smart-contract (initially this will be just a contract that can invoke "change this address to a new one" function in the Treasury smart-contract).

This sounds reasonable. I am supporting this idea, but the question is - who would be the initial members of the community contract? Propose a list of addresses and usernames.

Treasury contract must implement the following functions:

• "Change my address" function.
• "Change payment percentages" function.
• "Remove a receiver" function.
• "Add a new receiver" function.
• "Claim CLO rewards" function.

Why "claim CLO rewards" function can't claim everyones rewards is a bit unclear to me. We could avoid executing all functions by each party individually and eliminate two extra unnecessary txs on the network. I can hardly imagine a scenario where one party explicitly wants not to receive a reward from Treasury. Even if such a situation can occur - they can send CLO back to Treasury.

I would add "Receive CLO" function that would allow donations to be sent to the Treasury contract. I would also add "Receive ERC-223" function in case a donation is deposited in a form of ERC-223 token. Just a neat feature.

• "Change payment percentages" function. <== I would allow anyone to call this function, not only existing receivers. In this case any community member not part of the multisig will be allowed to initiate a voting session. Anyways it requires approval from the existing members of the msig.

In general I'm quite positive about this proposal.

[Upaut1]

Это звучит разумно. Я поддерживаю эту идею, но вопрос в том, кто будет первоначальными участниками общественного договора? Предложите список адресов и имен пользователей.

Я могу поработать в этом направлении, если Callisto Enterprise поддержит предложение по такому контракту казначейства. Мне нужно больше ясности и их точка зрения.

Почему функция «требовать вознаграждения CLO» не может требовать вознаграждения для всех, мне немного непонятно. Мы могли бы избежать выполнения всех функций каждой стороной индивидуально и исключить две лишние ненужные передачи в сети. Я с трудом могу представить себе сценарий, когда одна из сторон явно не желает получать вознаграждение от казначейства. Даже если такая ситуация может произойти – они могут отправить CLO обратно в Казначейство.

Любая сторона может назначить своим получателем адрес контракта. Этот контракт может намеренно или случайно не иметь возможности получения CLO (причины разные, ошибка при разработке контракта получателя, озлобленность одной стороны...). При таком сценарии ни одна сторона не сможет успешно завершить функцию «требовать вознаграждения CLO»

Я бы добавил функцию «Получить CLO», которая позволяла бы отправлять пожертвования в контракт Казначейства.

Я полагаю это функция и так "из коробки" будет, так как контракт обязан обрабатывать платежи в CLO, что поступают ему с каждого нового блока.

Я бы также добавил функцию «Получить ERC-223» в случае, если пожертвование вносится в виде токена ERC-223. Просто полезная функция.

Я против этого. Допустим контракт будет принимать токены ERC-223, как он должен делать выплату по этим токенам, согласно установленным процентам каждой из сторон? А что если получатель это контракт, не имеющий функции tokenReceived? Конечно можно в контракте казначейства сделать функцию, которая делает выплату только запрошенной стороне, но какой в ней смысл? Пожертвование могут делать не в контракт казначейства, а любому из получателей напрямую. Это навело меня на мысль, что контракт не сможет получать erc-223, но по прежнему будет получать erc-20, которые могут быть ошибочно отправлены ему, а значит данный момент надо отработать.

Чтобы не перегружать логикой контракт казначейства, предлагаю 100% пожертвований и 100% случайно отправленных токенов erc-20 передавать во владения community, для дальнейшего их распределения. Предлагаю сделать это следующим образом: В контракт казначейства добавить функцию tokenReceived для получения токенов erc-223, в теле которой сделать отправку всех получаемых токенов на адрес community. В контракт казначейства добавить функцию отправки токена erc-20 на адрес community

• Функция «Изменить процент оплаты». <== Я бы позволил кому угодно вызывать эту функцию, а не только существующим получателям. В этом случае любому члену сообщества, не участвующему в мультиподписи, будет разрешено инициировать сеанс голосования. В любом случае для этого требуется одобрение существующих членов msig.

Я боюсь что может быть спам из предложений.