Aragon Flock proposal: Aragon Black

Hey @mariapaulafn,

Thanks for your feedback :slight_smile:

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!

Bests.

2 Likes

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?

1 Like

Yep, that’s the goal. It won’t happen in the next coming months though :slight_smile:

4 Likes

@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.

2 Likes

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.

2 Likes

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. :slight_smile:

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.

4 Likes

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.

Hey @themathematicianisin,

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 :slight_smile:

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 … :frowning:

1 Like

Hey @stellarmagnet,

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!

3 Likes