Flora

[lkngtn]

Flora is an initiative to create a Proof of Authority EVM blockchain that is bridged to Ethereum. The goal is to provide a reliable and inexpensive network to deploy organizations which do not benefit from sovereign grade censorship resistance.

The chain will use DAI as its native asset, providing price stability and legibility for transaction fees. The validator set will be governed by a two step approval process, where an existing validator must propose the addition or removal of validators from the set, and Honey holders are required to either accept or reject such proposals.

Honey is an ERC20 utility token used to govern the 1Hive DAO. It grants the holder a discount on transaction fees when operating on the Flora sidechain, if a user activates sufficient Honey they are able to perform a certain amount of transactions for free.

The Honey token is bridged between Flora and Ethereum. We can support bi-directional bridges for other popular tokens including ANT, DAI, WETH as well as tokens created natively on Flora.

On Ethereum, Honey can be minted via depositing specific assets into a bonding curve (ANT, DAI) using Aragon's Fundraising app which serves to provide liquidity for the token and strategic alignment between 1Hive and Aragon.

poa.network provides much of the infrastructure we would need to support this initiative including an open source block explorer, token bridge, and Proof of Authority EVM node software.

[yeqbfgxjiq]

Hmmm this could actually be really useful for a project like Daonuts. Why would 1Hive specifically be taking this on though? How does it fit within our meta goal of making open source thrive?

[lkngtn]

Open source communities generally do not need sovereign grade censorship resistance and so are not necessarily well served by deploying to Ethereum mainnet.

Why would 1Hive specifically be taking this on though

Because no one else has and it's a great opportunity to fulfill a need while generating value for the project.

[yeqbfgxjiq]

I'm open to being convinced otherwise, but I see this as something that primarily creates value for the Aragon ecosystem and 1Hive benefits as well (vs the other way around). As someone who's volunteering my time/energy to work on 1Hive I'm doing so because I want to make open source more fun, sustainable, and manageable. As someone involved with multiple Aragon related projects I see the value of a sidechain to reduce tx fees and improve throughput. It's a great idea and the Aragon ecosystem needs something like this, but I don't think it directly aligns with the mission of 1Hive.

[lkngtn]

It’s certainly not zero sum. The fact that it creates value for the wider Aragon ecosystem as well as very specifically for 1Hive should be seen as an obvious win.

The way I see... 1Hive is trying to help open source communities thrive.

To do that we need to improve how open source projects attract patrons and reward contributors.

We believe that software defined organizations are key to achieving that.

• A software defined organization is transparent and allows patrons to see how funds are being allocated.

• A software defined organization is programable, making it easy for organizations to assign financial rewards and governance permissions.

We have determined that Aragon is the best framework to build software defined organization (we are using it, and many of our core contributors are involved in the Aragon ecosystem in one way or another)

But in order to make these tools useful for open source communities we need to make sure that they are easy and cheap to use.

Besides, if nothing else this work would turn Honey into a valuable utility token, that would increase in value as transaction volume increases on the Flora sidechain.

I would be happy to see Aragon support something like this, perhaps even funding a team to build and maintain the chain then using ANT directly as the discount token... However I think a derivative token / bonding curve approach as I propose here aligns incentives much better over the long term than a grant would.

[yeqbfgxjiq]

in order to make these tools useful for open source communities we need to make sure that they are easy and cheap to use.

Agreed

if nothing else this work would turn Honey into a valuable utility token, that would increase in value as transaction volume increases on the Flora sidechain.

I don't see the goal of HONEY as becoming a valuable token, but to become a way for the 1Hive community to reward contributors and give them more stake/reputation in the org. Being able to exchange that against a bonding curve or market is useful in that goal, but taking on side projects to just boost the value of HONEY is not in line with that goal.

I think a derivative token / bonding curve approach as I propose here aligns incentives much better over the long term than a grant would.

I don't see what you're seeing. Please explain more

[lkngtn]

I don't see the goal of HONEY as becoming a valuable token, but to become a way for the 1Hive community to reward contributors and give them more stake/reputation in the org. Being able to exchange that against a bonding curve or market is useful in that goal, but taking on side projects to just boost the value of HONEY is not in line with that goal.

If the intention is to use Honey to reward contributors, it's beneficial if those rewards have some utility/value associated with them. Patronage as a baseline utility is a reasonable use of bonding curves, patrons supply capital and in return get some special privileges, perhaps signaling on priorities for developers, perhaps getting priority support when bugs are encountered, or whatever makes sense for the maintainers to offer the contributors. In the case of Flora, one of those perks would be discounts and governance rights over validators on the Flora sidechain.

The goal isn't just to boost the value of Honey, its to build infrastructure that is critical for open source communities to effectively use DAOs (and to a certain degree onboard to web3 in general). Having the initiative tied to an economic model of patronage and granting patrons specific rights and privileges is just an example of dogfooding the model that we are proposing other projects adopt.

I think a derivative token / bonding curve approach as I propose here aligns incentives much better over the long term than a grant would.

A grant is essentially a contracting relationship, where you get paid X to do Y deliverable. It doesn't really do anything to create long term alignment. So for example Aragon could decide that a POA sidechain with Aragon deployed and ANT bridged would be useful, and can give a grant to someone to build and maintain that, but the maintainer is only really being paid for those deliverables, there is no additional upside if the poa network gains traction. There is also no upside for Aragon/ANT holders to support that specific initiative.

In contrast a derivative token / bonded token model like I'm proposing has a completely different dynamic. The builders/maintainers of the network initially will have early access to Honey when the network is not heavily used. They then have an incentive for the network to be successful as the value of the discount token will only increase if the network gains traction. It's not sufficient to just deploy and operate the network, people have to use the network. Similarly, since the bonding curve serves to lock up ANT, it encourage ANT holders and the Aragon project to support the chain. So unlike the grant, both the builders/maintainers and the larger ecosystem are all aligned around the network actually gaining traction and being used.

[yeqbfgxjiq]

Ok cool. I'm starting to warm up to the idea. Like I said in our Keybase chats (sorry for the multi threaded convo lol) if open source projects can use the sidechain to host a DAO for their community at a discount (or free) that would be awesome. Then regular users would pay to support ongoing maintenance/improvements which would support 1Hive, the broader Aragon ecosystem, and esp open source projects. I'd be on board with that.
Since a lot of projects in the Blockchain space have open source code, we could further restrict this condition to FLOSS projects that release their code and product completely free.

[john-light]

Because no one else has and it's a great opportunity to fulfill a need while generating value for the project.

You don't consider xDAI to be a good solution for this?

[lkngtn]

You don't consider xDAI to be a good solution for this?

I think xDAI is a good solution for short-term scalability, but I think that introducing a discount token model to a POA or DPOS sidechain is a significantly better solution because it improves alignment between the users of the chain and the validators that run the chain. POA is providing infrastructure for organizations to bootstrap their own chain as well (this is a call to action on their homepage), so the bulk of the work here should be on implementing the discount token model not engineering the chain itself.

The disount token is always move valuable to people who are actively using a service (because they are able to realize the value of exercising the discounts), section 2.8 in the linked paper goes into a more formal explanation of this. But the interesting thing is that this mechanic means that since users will be able to realize more value from the asset than passive speculators, the market forces should result in the token distribution being more representative of actual user interests.

This ends up being a bit more upfront work to develop the discount token model and bootstrap the sidechain, but it seem like enough of an innovation to warrant that upfront work.

[DISC30]

How scalable and free is PoA/DPoS? Especially if we want to implement decision-making and resource allocation by the (global) collective.

"Anatoly watched as blockchain systems without clocks, such as Bitcoin and Ethereum, struggled to scale beyond 15 transactions per second worldwide when centralized payment systems such as Visa required peaks of 65,000 tps. Without a clock, it was clear they'd never graduate to being the global payment system or global supercomputer most had dreamed them to be. When Anatoly solved the problem of getting computers that don’t trust each other to agree on time, he knew he had the key to bring 40 years of distributed systems research to the world of blockchain. The resulting cluster wouldn't be just 10 times faster, or a 100 times, or a 1,000 times, but 10,000 times faster, right out of the gate!

Anatoly's implementation began in a private codebase and was implemented in the C programming language. Greg Fitzgerald, who had previously worked with Anatoly at semiconductor giant Qualcomm Incorporated, encouraged him to reimplement the project in the Rust programming language. Greg had worked on the LLVM compiler infrastructure, which underlies both the Clang C/C++ compiler as well as the Rust compiler. Greg claimed that the language's safety guarantees would improve software productivity and that its lack of a garbage collector would allow programs to perform as well as those written in C. Anatoly gave it a shot and just two weeks later, had migrated his entire codebase to Rust. Sold. With plans to weave all the world's transactions together on a single, scalable blockchain, Anatoly called the project Loom."

https://solana-labs.github.io/book/introduction.html