Почему мы выбрали ERC-721, а не ERC-20 для контракта получателя дивидендов

[gwisp]

При таком подходе получается, что доля кратна 1%. А если делать доли более делимые, то у одного инвестора будет очень много токенов, и каждым надо будет воспользоваться по отдельности, заплатив очень много газа. Да и при 1% газа может много уходить. А ещё сложно торговать долями будет, потому что рыночная стоимость доли зависит от накопленного дохода, который постоянно меняется. Для решения той же проблемы на обычных биржах при торговле облигациями покупатель должен ещё в добавок заплатить автоматически вычисляемый накопленный купонный доход, но не знаю, есть ли что-то аналогичное в мире криптовалют.

Кажется, следующая схема на ERC-20 была бы лучше. Но возможно я изобретаю велосипед.

1. У каждого инвестора есть накопленный доход, также вместе с этим хранится общий доход контракта на момент расчёта накопленного дохода

2. При переводе токенов между инвесторами накопленный доход обоих пересчитывается, используя разницу между текущим общим доходом контракта и общим доходом на момент предыдущего расчёта накопленного дохода

3. Инвесторы забирают весь свой доход одним вызовом контракта

Из недостатков схемы - невозможность дополнительного выпуска токенов или их сжигания, потому что при этих операциях пришлось бы пересчитать накопленный доход всех инвесторов.

[xni]

Не подумал о таком подходе. Да, выглядит резонно!

В случае ERC-721 в принципе тоже можно ввести "вес" токена, не обязательно там 1%. Но тогда получается какое-то прям переусложнение.

[mtiutin]

Чтобы решить задачу распределения дивидендов 1 транзой для ERC-20, можно адаптировать подход фармилки MasterChef (0xc2EdaD668740f1aA35E4D8f227fB8E17dcA888Cd) Там используется мультипликатор accPerShare, который показывает накопление дохода в расчете на 1 акцию. Распределение дохода = пересчитать и увеличить accPerShare. Проблемы с mint и burn акций там тоже решены и сопровождаются выплатой купонного дохода. В общем, я такую задачу вполне успешно решил на базе подхода вышеуказанного контракта.

[xni]

Прошу прощения за минус, промахнулся с кнопкой "Ответить" и не могу изменить обратно... С меня плюс к вашему следующему комментарию просто так :)

Посмотрел я тот контракт, и не нашел там accPerShare, это раз. Два - это вопрос о том как все же помечать что какой-то владелец уже забрал свои дивиденты, а какой-то еще нет?

[mtiutin]

1. конкретно в том контракте он accSushiPerShare. Сорян. Просто я их уже несколько штук видел, название токена посредине все меняют на свой лад...

2. Фактически, пометка о том, "по куда" юзер забрал свою награду (дивиденды) делается вот здесь:
   user.rewardDebt = user.amount.mul(pool.accSushiPerShare).div(1e12);
   следующий раз, когда он будет забирать токены, это значение будет отниматься:
   uint256 pending = user.amount.mul(pool.accSushiPerShare).div(1e12).sub(user.rewardDebt);
рекомендую сделать тестовый пример в табличке в екселе с параметрами контракта (одного пула и 2 юзеров, допустим), и расписать (по коду), как они меняются при транзакциях. так будет понятнее.

[xni]

Теперь вижу, прочитал, спасибо!

Да, идея понятна, это как раз то о чем говорили и тут https://habr.com/ru/post/668924/comments/#comment_24396864

Ключевым отличием является невозможность этой схемы не забирать свой профит, а так и оставить его лежать. Ну и в целом механика кажется чуть более громоздкая: когда ты приходишь с каким-то количеством LP токенов, тебя заносят в реестр, ты после этого получаешь виртуальный "долг" - чтобы ты как будто бы был с самого начала, но снял все под 0 вчера, и тд итп., чтобы у них все сошлось.

Но в целом да, интересно, спасибо!