у контрактов токена

Чтобы отправлять токены, нужно уметь работать с токенным контрактом. А чтобы работать с токенным контрактом, нужно либо хардкодить сигнатуру вызовов в нашем контракте, либо позволять выполнять вообще любой call (что и делает мультисиг)

Ну и всякие гибридные модели возможны

да

сигнатуру метода подаем на вход получается

Ага. Понял, спасибо.

Коллеги, помогите пожалуйста советом.
Мы уже провели ICO и задеплоили часть контратов с токенами, теперь придумали еще много функционала, и один из новых контрактов стал очень большим и занимается фактически двумя независимыми областями, назовем его MasterContract.
Я начал думать по поводу того, что вынести эти два функционала в две библиотеки и вызывать их из тела MasterContract1, таким образом у меня ссылки на уже задеплоиными контракты остаются в MasterContract и security работает также, а логика уезжает в библиотеки. Нет ли каких-то косяков в этой имплементации? Спасибо
p.s. Косяков типа, обращения к аттрибутам контракта из библиотек, или фокусов с msg.sender при вызове library из контракта и наоборот

Фигасе!

привет

есть спецы по блокчейнуу?

Есть

других не держем

походил по гитхабам проектов, которые уже проводят или провели ICO, позаходил в контракты, потом в аккаунты тех, кто там поблеймился, увидел форки контрактов более известных крипто-проектов, посравнивал между собой, норм

в чем тогда заключается работа DApp-девелопера, если проект имеет дело с эфиром, работает на основе его блокчейна, а бойлерплейты простых контрактов доступны везде хоть где?

так, ну, не хотел никого задеть :D просто удивительно как проекты с базовыми схемами начисления и транзакций собирают уйму внимания. я верю, например, что тот же саундчейн имеет дофига сложные схемы. просто, как мне кажется, главный человек в разработке контракта  — вовсе не программист

etheredelta

ethlance

нормальные решения

относительно*)