Open Dexaran opened 6 months ago
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.
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.
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.
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.
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 :
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
Предлагаю адрес казначейства сделать контрактом, в котором будет разделение казны на 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, чтобы для каждой такой выплаты не собирать подписи.
@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
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.
Callisto Enterprise, Callisto Network, Community will be called "receivers" below.
Treasury contract must implement the following functions:
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.
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.
In general I'm quite positive about this proposal.
Это звучит разумно. Я поддерживаю эту идею, но вопрос в том, кто будет первоначальными участниками общественного договора? Предложите список адресов и имен пользователей.
Я могу поработать в этом направлении, если 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.
Я боюсь что может быть спам из предложений.
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:
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
Copyright
This CLOIP is placed under the CC0-1.0.