Thanks for your feedback
Task management is a wide-issue. The Planning Suite / Autark team is working on providing task management into Aragon. AFAIK [but I let @stellarmagnet confirm] part of this task-management apps rely on github issues.
The plan in the mid-term is to integrate a decentralized / IPFS based issue system into pando apps and to work with the TPS / Autark team to integrate this decentralized issue system in TPS [basically letting the user decide whether they wanna rely on pando issues or github issues].
This is something we have in mind for a while and did a lot of research on [especially towards OrbitDB]. Though, before we start actively working on that, we need to solve the more generic IPFS / pinning issue.
So the short-term plan is to work on this problem first by providing a almost solid pinning system for Aragon users. Then, we’ll work on developing a decentralized issue system on top of this pinning service. Finally, we’ll be able to work with TPS / Autark to integrate pando issue system into TPS and provide users with a fully decentralized task management solution.
I hope this answer your question!
Thanks a lot! Does make sense and sorry for the confusion.
Do you envision a possibility to replace Github for Pando in Autark’s planning suit?
Yep, that’s the goal. It won’t happen in the next coming months though
@DanielS that graphic you made about the team composition and roles is great!
I just wanted to add a follow up response that I am really excited about this AGP – thanks for all of the additional background and details @DanielS and @osarrouy.
I’m also looking forward to the future integration of Pando into That Planning Suite – I especially find decentralized issue/task management very important, and focusing on how we can move the AGPs off Github.
If we have the bandwidth in the next 4 months we are going to try to dedicate time to enhancements that will make the integration more seamless.
Hi Aragon Black and other teams! I took a look at your fundraising bonding curve/tap system and recommend an augmented bonding curve (https://medium.com/giveth/deep-dive-augmented-bonding-curves-3f1f7c1fa751), basically:
The token bonding curve R=S^k/V0 determines the token buy price (Price Function) P=dR/dS in terms of the current reserve amount R. This buy price = sell price = token value is ensured/stabilized/backed by an additional amount which added to the buy price gives the actual buy price (Realized Price). Optionally, you can set a hatch phase to prevent withdrawing too early and a withdrawal fee (liquidation friction fee) to add more funds to the community fund.
The nice thing is, it’s a continuous self-sustaining fully-backed bonding curve, and everything’s in terms of the current amount of reserve funds! The only need for a tap is for, say, a timeline of dispersal for community fund contributions.
Blockscience and Giveth’s work on augmented bonding curves is excellent, I’m a big fan. I would love to see some sort of collaboration or simply the continued cross-pollination of code and ideas related to bonding curve based fundraising.
There has been some discussion related to whether it makes sense for apiary to use the tap mechanism versus directing a percentage of buys or sells into the discretionary pool (similar to what is described in the augmented bonding curves post). I tend to prefer the tap mechanism because it creates a flow of funds that is not strictly dependent on ongoing trading volume. Is there a specific reason you prefer the fee/tax/spread model over a continuous tap?
Regardless, I think it is reasonable to support both approaches and I believe @osarrouy may have already built in support for this into the contracts as we think it is best if the system is flexible and can meet many different use cases. I believe the fee/tax/spread on buy and sell approach is also used in the continuous org model.
I think the vesting is also really useful as a design pattern, and I expect there will be support for adding vesting requirements, though I’m not sure if this will make it into an initial release or not. I would also love to see the concept of “hatching” be made a bit more flexible, so that someone could start an organization that is not associated with a bonding curve (eg just uses the standard token manager) to bootstrap by assigning tokens to contributors and then later choose to “go public” by attaching the pre-existing token to a bonding curve.
Yes giving DAOs flexibility to customize the features to their own needs is a huge plus!
I don’t have a preference for either discrete payments or continuous taps, they are both valid implementations for payment timelines.
Super interested in what Blockscience is working on too. As stated by Luke most of what would be needed is already [almost] there:
- The current bonding curve already handles buy / sell fees.
- The bonded token is handled through a token manager which already supports vesting. The only issue I would see here would come from the UX / user flow. Because it would mean that to redeem some of its bonded token, a user would first need to pick one of its vested package, unlock some tokens out of it [with respect to the vesting slope], then create a sell order, then clear this sell order. That would be quite a long and cumbersome flow
I believe one more difference between what we and Blockscience do comes from the type of chain we intend to build on: we are heading towards an Ethereum deployment while, AFAIK, Blockscience intends to deploy on the xDAI chain [a DAI based PoA chain]. So the gas constraints would not be the same. And I can tell you: the system we have now [which is simpler than the one design by Blockscience] is already on the edge of what the Ethereum mainchain allows in term of complexity …
Super excited to work on this integration too. I guess the only blocking point for now is the choice of a good decentralized database for the issue system but the call we’ve had with @Schwartz10 about that has been super productive so I hope we can all move forward on that in the next coming months!