{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "current-problems-with-fractals-and-the-meeting-schedule"
    }
  ],
  "block": 91910881,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2024-12-27T10:02:57",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment",
    {
      "body": "Congratulations @sim31! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)\n\n<table><tr><td><img src=\"https://images.hive.blog/60x70/https://hivebuzz.me/@sim31/posts.png?202412201111\"></td><td>You published more than 20 posts.<br>Your next target is to reach 30 posts.</td></tr>\n</table>\n\n<sub>_You can view your badges on [your board](https://hivebuzz.me/@sim31) and compare yourself to others in the [Ranking](https://hivebuzz.me/ranking)_</sub>\n<sub>_If you no longer want to receive notifications, reply to this comment with the word_ `STOP`</sub>\n\n",
      "title": "",
      "author": "hivebuzz",
      "permlink": "notify-1734693218",
      "json_metadata": "{\"image\":[\"https://hivebuzz.me/notify.t6.png\"]}",
      "parent_author": "sim31",
      "parent_permlink": "current-problems-with-fractals-and-the-meeting-schedule"
    }
  ],
  "block": 91710994,
  "trx_id": "0cb6510edb881c1fb38bafed73d7ae8b465ae7a0",
  "op_in_trx": 0,
  "timestamp": "2024-12-20T11:13:39",
  "virtual_op": false,
  "trx_in_block": 38
}

{
  "op": [
    "comment",
    {
      "body": "This post will consider some of the problems I currently see in Optimism Fractal and Eden Fractal and how to fix them. First I present an overview of the motivations (problems) and then I present one potential solution that involves the creation of project-specific fractals to address specific needs of Optimism Fractal while keeping average meeting frequency across all fractals the same as in [currently passed proposal](https://snapshot.box/#/s:optimismfractal.eth/proposal/0x44d911c3376512bb7dc0377aef7e9230d537a3d117c59e19d11623230d624d3e).\n\n## Motivation\n\n### Relationship between meeting cadence vs level of detail and size of contributions\nAs the period of time between meetings increases people will be able to do more work in between meetings which means that:\n* the level of detail in presentations of contributions decreases;\n* the impact of the presented contributions increases;\n* comprehensiveness for a larger number of people increases (potential userbase (participants of the meeting) and potential audience of recorded videos expands);\n\nNow this relates in an interesting way to the mission of a fractal (and in turn the respect-game prompt of a fractal). The more specific the mission of a fractal the more often it makes sense for people to meet. That's because they are aligned more and benefit an increased level of detail in the presentation of contributions.\n\nOn the other hand, a more general mission of a fractal means that a longer time period makes more sense because people will come from vastly different backgrounds, which means that:\n* they will be less familiar with each other's work, and so they would benefit from a decreased level of detail in presentations and more impactful contributions being presented (makes respect game process more understandable and valuable for them);\n* possibilities of collaboration decrease, which, in turn, means less benefit from more frequent meetings;\n\nDoes that make sense?\n\n**If it does then I would argue that Optimism Fractal meetings should happen twice as often as EdenFractal meetings.**\n\n### The need for smaller fractals to test the next versions of fractal apps\nTesting (and testing with other people in particular) is a key part of development and if we want our meetings to be friendly for newcomers and not have anything break every other release, we have to test our apps before deploying them to the main fractals. We have to test them in an environment and use cases that are as close to those of production as possible.\n\n### The need to separate testing and support from the development of new features\nFrom my experience, successful development requires a combination of different conflicting perspectives. I would express my best current approximation of them like this:\n* Delivering - getting things done in a timely manner (hitting deadlines, but scope and quality have to become flexible - you might need to compromise on them);\n* Developing - developing a system in a way that does not compromise the quality of a system. Avoiding [technical debt](https://en.wikipedia.org/wiki/Technical_debt) (but then timing and/or scope has to become flexible);\n* Testing and support - fixing stuff, improving reliability while avoiding big destabilizing changes;\n\nThe thing is that these approaches are conflicting - I can apply only one of them at a time, but you need all of them.\n\nAnother key thing is that the third mode is often compatible with work on other projects (because it's least demanding most of the time), while the other two are much harder to balance with other projects.\n\nI'm mentioning this because this is relevant to the schedule question which I will consider later.\n\nThis is partly inspired by [project management triangle](https://en.wikipedia.org//wiki/Project_management_triangle).\n\n### The need for funding\nFunding is a key problem for fractals right now and I think it is time to focus on it. We need to reward contributors to sustain current development and invite more developers.\n\nFor the kind of fractals that EdenFractal and OptimismFractal are, we need a unique solution (not something that other DAOs use). Of course, it is up to the community to decide but from my perspective principles on which we have been building these fractals so far would be broken if we adopt any of the solutions other DAOs use.\n\nA lot can be discussed here and I don't think my perspective is perfect. Which brings me to the next point...\n\n### The need for more deliberation on key issues of a fractal\nOne thing we had in EdenFractal that I miss right now is more focused discussions where we try to reach consensus on a key issues of a fractal. This is where a lot of good ideas were born.\n\nNow we [Optimism Town Hall](https://optimismtownhall.com/), but it is not quite the same. I think partly because in EdenFractal we had a consensus process that required a successful vote *during* the meeting to pass a proposal. This task to pass or reject a proposal I think is a key ingredient to make discussions more productive and motivate people to join. By \"productive\" I mean that people come from them having learned something (so it is not just about proposals being passed - I consider a lot of EdenFractal meetings where we did not pass any proposals to have been very productive). Anyway, with a biweekly schedule we will have those meetings even more rarely.\n\n#### Potential solution: sub-fractal of OF focused on one specific problem\nI'm not suggesting going back to what EdenFractal was doing, but I think we can arrive at the same benefits in a different (better) way:\n\n* Create a fractal whose mission would be to solve one specific problem. For example, a fractal with a mission to solve funding problems for Optimism Fractal.\n* Structure its meetings into two parts: the first part focuses on proposals, the second on respect game with a prompt - \"who contributed the most to the discussion in this meeting\".\n\nI think this model (with a more focused goal and opposite meeting structure to what we have now) is superior to what we were doing in EdenFractal. The great thing about this kind of structure is that it awards (with respect) people for listening to each other and integrating each other's perspectives. If someone modifies their proposal to integrate my ideas, I will likely rank him highly in a game about \"who contributed most value to the discussion?\"\n\nI think we need something like this to solve the funding problem.\n\n## A schedule derived from the considerations above\n*First draft*\n\nSo we have 3 types of fractals:\n* Project-specific (projects of Optimism Fractal);\n* Platform specific (Optimism Fractal);\n* Eden Fractal (whole fractal ecosystem);\n\nThe full cycle would last 7 weeks. Each cycle would be divided into two parts, 4 weeks each, with 1 week in the middle where these parts overlap:\n\n| Weeks | Meetings         | App development state |\n|-------|------------------|-----------------------|\n| 1-4   | Project-specific | Testing and support   |\n| 4-7   | OF and EF        | Development           |\n\nSo new app versions would first be deployed to project-specific fractals and tested and refined there during weeks 1-4. Then once they would reach maturity they would get deployed to Optimism fractal at which point I would start developing a new version.\n\nWeek by week schedule of meetings could look like this:\n\n1. Project-specific meeting\n2. Project-specific meeting\n3. Project-specific meeting\n4. Project-specific and Optimism Fractal meetings\n5. Eden Fractal meeting\n6. Optimism Fractal meeting\n7. Break from meetings\n\nDuring the 7th week, people have time to reflect and decide what project-specific meetings to participate in during the next cycle. We could have polls where people would express what meetings they would participate in and at what times. No need to reach consensus on this - people will just gather in meetings that are meaningful for them. I suspect there will be one type of project-specific meeting per week, but there can be more. Furthermore, if there are more than 6-8 people who want to solve a particular issue, or if people are split regarding what time to use, multiple working groups could be formed that would meet at different times.\n\n### Key features:\n* That's 7 meetings in 7 weeks - the same average frequency of meetings as in the current proposal that was passed;\n* 4 project meetings, 2 OF meetings, 1 EF meeting per cycle. 3 levels of fractals, from project-specific to EF encompassing the whole ecosystem, structured according to the \"Relationship between meeting cadence vs level of detail and size of contributions\" I talked about in the beginning;\n* Compatible with the development process of the fractal app in a way where I can focus on participating in specific projects and discussions for Optimism Fractal as well as provide consistent development and support;\n* Enable easy transition to big upgrades of a fractal app or even switching to a new fractal app. - Simply create a project fractal for this upgrade and discuss, test, and pass a proposal to start using it there;\n* Newest versions would first get tested in smaller project-specific fractals. This makes sense because main OF meetings are core to Optimism Fractal and there is more damage if something does not work in them.\n  * New people are more likely to join OF and EF first before entering project-specific fractals. I think you will agree that we want newcomers to have a smooth experience, so it makes sense to test in smaller project-specific fractals first;\n  * Also more frequent meetings reduce the importance of individual meetings (inflation of meetings) which makes fractals with more frequent meetings more suitable for experimenting with new versions of the app (less is at stake);\n\n## Conclusion\nAbout half a year ago I wrote [an article called \"Embracing competition within fractals\"](https://peakd.com/dao/@sim31/embracing-competition-within-fractals). Now here, I urge us to come back to consensus building. We need both aspects, but to apply them to the right areas and at the right times.\n\nCompetition made more sense at the time of that article when it came to implementations of fractal apps. Firstly because there was no one developing a fractal app at the time for Optimism Fractal, so any kind of development needed to be welcomed. Secondly, because we already had enough consensus building about fractal app design before and even though we did not arrive at consensus it was crucial for me to understand what the needs are and what is more likely to be accepted by the community. This is a key point: if done the right way consensus building process provides benefits even if it does not produce consensus. It creates a very good setting for understanding needs and coming up with ideas.\n\nNow I don't think we had enough consensus building on how to solve funding problems for Optimism Fractal yet, therefore I think it makes sense to start that.\n\n**The kind of schedule I propose above creates an environment fitting for both competition as well as consensus building. The first part of a cycle is geared towards consensus building, while the second is more fitting for everyone to develop their own solutions. This should create the right balance between these competing perspectives.**\n\n\n",
      "title": "Current problems with fractals and the meeting schedule",
      "author": "sim31",
      "permlink": "current-problems-with-fractals-and-the-meeting-schedule",
      "json_metadata": "{\"app\":\"peakd/2024.12.5\",\"format\":\"markdown\",\"description\":\"Problems with fractal DAOs and their relationship to types of meetings and their schedule\",\"tags\":[\"dao\",\"governance\",\"consensus\",\"blockchain\",\"optimism-fractal\",\"eden-fractal\",\"fractally\"],\"users\":[\"sim31\"],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 91709581,
  "trx_id": "41f9f779f9998558c168958cba978dbbd5d5b796",
  "op_in_trx": 0,
  "timestamp": "2024-12-20T10:03:00",
  "virtual_op": false,
  "trx_in_block": 2
}

{
  "op": [
    "transfer",
    {
      "to": "sim31",
      "from": "therealwolf",
      "memo": "Hey there sim31. I hope you don’t mind this short message, but I wanted to quickly share this update with you on my Hive-related work. For the past 7 years, I've been deeply committed to Hive, working on projects like hive.io, vessel, dhive & more to strengthen our community, while providing reliable witness infrastructure to secure our blockchain. Recently, I've released an upgraded witness toolkit (peakd.com/@therealwolf/major-hive-witness-essentials-upgrade-v2) and celebrated 7+ years on Hive (peakd.com/@therealwolf/year-8). If you'd like to support my work, I'd be honored to have your witness vote. Thank you! PS: You can vote for me here: peakd.com/witnesses",
      "amount": "0.002 HIVE"
    }
  ],
  "block": 90679160,
  "trx_id": "802a00a02e9b04963edd5c4c9158832e2114b6e4",
  "op_in_trx": 15,
  "timestamp": "2024-11-14T13:22:45",
  "virtual_op": false,
  "trx_in_block": 10
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "embracing-competition-within-fractals"
    }
  ],
  "block": 85652329,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2024-05-23T15:48:51",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "kemonine",
      "author": "sim31",
      "weight": 12936326415,
      "rshares": 12936326415,
      "permlink": "embracing-competition-within-fractals",
      "pending_payout": "0.013 HBD",
      "total_vote_weight": 31118434764
    }
  ],
  "block": 85451107,
  "trx_id": "526e6028cd4ca872451ea9526967be6da3f21a27",
  "op_in_trx": 1,
  "timestamp": "2024-05-16T15:57:54",
  "virtual_op": true,
  "trx_in_block": 5
}

{
  "op": [
    "vote",
    {
      "voter": "kemonine",
      "author": "sim31",
      "weight": 5000,
      "permlink": "embracing-competition-within-fractals"
    }
  ],
  "block": 85451107,
  "trx_id": "526e6028cd4ca872451ea9526967be6da3f21a27",
  "op_in_trx": 0,
  "timestamp": "2024-05-16T15:57:54",
  "virtual_op": false,
  "trx_in_block": 5
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "emsenn0",
      "author": "sim31",
      "weight": 13822757620,
      "rshares": 13822757620,
      "permlink": "embracing-competition-within-fractals",
      "pending_payout": "0.007 HBD",
      "total_vote_weight": 18182108349
    }
  ],
  "block": 85451105,
  "trx_id": "b3e92591a4bc5ff80dc9aa408c9987e8dff8a354",
  "op_in_trx": 1,
  "timestamp": "2024-05-16T15:57:48",
  "virtual_op": true,
  "trx_in_block": 29
}

{
  "op": [
    "vote",
    {
      "voter": "emsenn0",
      "author": "sim31",
      "weight": 10000,
      "permlink": "embracing-competition-within-fractals"
    }
  ],
  "block": 85451105,
  "trx_id": "b3e92591a4bc5ff80dc9aa408c9987e8dff8a354",
  "op_in_trx": 0,
  "timestamp": "2024-05-16T15:57:48",
  "virtual_op": false,
  "trx_in_block": 29
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 4359350729,
      "rshares": 4359350729,
      "permlink": "embracing-competition-within-fractals",
      "pending_payout": "0.001 HBD",
      "total_vote_weight": 4359350729
    }
  ],
  "block": 85451103,
  "trx_id": "510f94521d3fac45bba7f1cd096e38e4c985c3dd",
  "op_in_trx": 1,
  "timestamp": "2024-05-16T15:57:42",
  "virtual_op": true,
  "trx_in_block": 9
}

{
  "op": [
    "vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 10000,
      "permlink": "embracing-competition-within-fractals"
    }
  ],
  "block": 85451103,
  "trx_id": "510f94521d3fac45bba7f1cd096e38e4c985c3dd",
  "op_in_trx": 0,
  "timestamp": "2024-05-16T15:57:42",
  "virtual_op": false,
  "trx_in_block": 9
}

{
  "op": [
    "comment",
    {
      "body": "Over the last half a year or so when it comes to contributing to fractal DAOs, my perspective has been about prioritizing consensus before doing. I thought that we have to build consensus on what to do next as a group and then do it together in a coordinated way. This did bring some positive results\n\n* We were able to coordinate replicating our old processes in a new environment (workflows we used on EOS being replicated on Optimism as Optimism Fractal);\n* We generated loads of new ideas;\n* We reached consensus on a vision and mission statement of EdenFractal;\n\nHowever one of my expectations for this period of time was that we would upgrade Optimism Fractal software. It was clear that the current design of it was sub-optimal. And so, in line with my perspective that we ought to do things together, I tried to reach consensus on how we want to do it (development process) and what we want to do (design of a new Optimism Fractal software). Even though I spent a lot of time collaborating on this with others the result was a failure - almost no progress was made on updating Optimism Fractal software (we have produced multiple potential designs though).\n\nI conclude that when it comes to the design and development of software for fractals it is not something that group consensus should even be deciding. **Group consensus can decide what software to use, but it cannot efficiently decide what software to create.** Or in other words, group consensus is great at judging and selecting software, but it is terrible at creating new software (unless you're replicating what's already done).\n\n## Linux development model\nObviously, I'm not saying that groups of people cannot create software well. I'm saying that *decentralized group consensus* cannot create software. So you either have to have a hierarchical management structure for decision-making or use an open source Linux-like model.\n\nLinux is probably the most successful global collaborative software project that has ever existed. If we want to do decentralized collaboration it's a no-brainer that we should look to learn from it.\n\nHow does Linux manage to be such a successful decentralized collaborative project without any management hierarchy? The trick is that the maintainers of Linux codebase do not try to direct the development. They simply either accept or reject the code already developed. This saves a huge amount of overhead. There are many other benefits and interesting features of Linux development process[^1] but one of the things I want to mention here is that this is the thing that enables Linux to have so many contributors. If they tried to manage developers then adding every new developer would add add communication overhead, which would eventually limit the amount of developers that could work on a project. If you don't try to do top-down management of development you simply do not have this problem.\n\nThe group of maintainers that maintain Linux repository have a hierarchical structure where each subsystem of Linux has one maintainer and the top maintainer acts as a final gatekeeper for what gets merged. The top maintainer usually also appoints maintainers for subsystems. This is an efficient structure for decision-making because final decisions have to be made by individuals, not groups.\n\nYou might think that this is a benevolent-dictator model, with the top-maintainer holding keys to change whole maintainer hierarchy as well as override any decisions they make. In a sense, you would be right. But you miss the point until you realize the limited scope of this dictatorship. Top-maintainer can only control one repository. Creating and cloning repositories is so easy and cheap, that it does not actually give top-maintainer much real power. If people stop liking decisions top-maintainer makes they can always start using a new repository. The only way for the current main repository to maintain its status as the main repository for a project is for the top-maintainer to make decisions that make everyone happy or at least are neutral and fair for everyone.\n\n## What can fractals can learn from Linux\nThe idea of not directing development but selecting what's already developed is even more relevant for fractals than it is for Linux. Fractals do not use the benevolent dictator model that Linux maintainers use. Typically the only means of making decisions for a fractal is the consensus process which usually takes at least 4-6 contributors agreeing on a proposal. Obviously, this makes it much harder to make decisions than in the Linux model. Therefore, if overhead in directing software development would be a problem for Linux it is even more a problem for fractals.\n\nThis does not mean that fractal should not have any control over its own code. It's just that this influence over the code should be exercised through selecting code rather than organizing the development of code (alternatively fractal would probably need to provide funding for developers in order to organize development effectively). Every time we select something we express our values, because we select according to our values. The same holds for fractals. Developers whose apps get rejected or accepted will get the message about values of a fractal and therefore they have information to make a better version next time. Furthermore, a more refined feedback mechanism could be created where developers would get comments about why their code was accepted/rejected, although that would probably happen naturally even without introducing any formalized process. If there are multiple candidates they could even be ranked.\n\nI propose that this principle of selecting over directing should be applied when creating and adopting all code for a fractal (deployed smart contracts as well as frontend).\n\nIt has to be noted that if there's no coordination in a fractal about who works on what it means that we will likely end up having multiple apps competing to be selected. Which brings me to my next point.\n\n## Contest for the next version of a fractal app\nWhat if instead of seeing the development of fractal software as a collaborative effort we embrace it as a contest that a fractal hosts? A place where developers (and teams of developers) compete to determine the best fractal DAO software with the winning software becoming the \"official\" app of a fractal?\n\nWhy would developers participate you ask? Of course, a fractal does not have any treasury and therefore cannot offer any prize or reward, so you might think a fractal does not have anything to give. This brings me to a very important point. A Fractal does have the most valuable thing to give: usage from real users. The usage of code is the main currency for an open source development. This is what motivates donations, grants and other types of funding in this ecosystem and with metric-based retroactive funding (RetroPGF) this is even more relevant. Fractals are great for anyone creating DAO software because they have users interested in decentralized governance and even more importantly they have great potential for onboarding new users.\n\nOne thing that struck me lately about my time in fractal DAOs is how often people put solutions before the problems (I'm surely guilty of this as well). In a typical discussion, you will get a bunch of ideas about what we could do and only later we talk about the problems we are solving and why we prioritize these problems over others. My theory is that this is a sign that we are unconscious of one of the needs we all have that fractal is serving us. A typical person in this space is creative and passionate. Visionaries - someone who has and follows his own vision. An important type of reward for this kind of person is to have his ideas and creations adopted, implemented, and spread. This is why, I believe, we put solutions before the problems so often. In short - it serves our need to be creators. More specifically, anytime someone adopts a solution we were inspired by, it confirms the vision we believe in and this confirmation energizes us in our pursuit of our vision, which makes us more psychologically healthy and happy.\n\nSo let's stop thinking that fractals have to somehow incentivize developers to contribute. The only thing a fractal needs to do is to give creative freedom for builders and then recognize and use their work. The usage of their work is the reward. There are enough builders who would love to have fractals use their software. The reason for the lack of development progress on fractals is because those builders have been trying to collaborate and learn what to build from a fractal instead of just building what they believe in and proposing it for a fractal. This can partly solved by a fractal clearly communicating that it is not going to tell anyone what to create and how, it will simply wait for completed products and then select the best.\n\n## Non-linear progress\nAnother part of a solution is to advertise and implement a non-linear development process. What do I mean by that? \n\nOne of the things that is often preventing us from creating effectively in the present is a concern that what we do right now will somehow eliminate our path towards our long-term vision. In other words, we have a long-term vision and we want to make sure that the step we make right now is aligned with that vision. This can be paralyzing. This is very relevant for DAOs the way we usually think about them. We assume that future updates have to be made by improving existing codebase, updating existing deployment of contracts. If this is true, that severely weakens the contest idea I suggested above. What would happen is that some ideas would get rejected during the first contest of competition and then implementers of those ideas would have to give up on their line of work, because they know that all updates will happen on a different line of work.\n\nI think this is a wrong perspective for fractals that have only non-transferable token and hold no assets (e.g.: Optimism Fractal Eden Fractal). These kinds of fractals can fork easily (use different smart contract deployed at a different address) and this should be utilized. It means that fractal can adopt completely different codebases from season to season. Ideally, these implementations would have the same interface but right now it only means that they have to implement a non-transferable token called Respect. It should be up to developers of these competing versions to offer a smooth path to migrate to their new deployment.\n\nThis is what I call non-linear type of development. It simply means that a fractal adopts a new version for the next season without having to ensure compatible with past and future development initiatives.\n\nFor the contest idea I suggested earlier, it means that developers who lose in the competition for this season can continue development of their version and win the next season. In fact, they would have an advantage over the current winner. The winner for this season will be busy supporting users and maintaining existing features while projects which lost can develop new features. Not to mention the potential multiplicity of fractals - so if you didn't win in a contest for one fractal you can try for others. \n\nThis creates an environment where there are no absolute losers. Only continuous competition with all competitors getting better and better. A recipe for a great sport.\n\n## Relationship between fractals, builders, and public goods funding programs\nThe standard relationship between a software developer and his client is that the client pays money and in exchange developer builds what the client wants. Public goods funding in the crypto space is different. Builders build what they want and if users find that valuable public good funding program tries to reward the builder appropriately. When compared with standard client-developer relationship builders here lose predictability with regards to their payment, but this is compensated by the creative freedom to build what they genuinely believe in. This is a trade-off that makes sense for a lot of builders in crypto space.\n\nSo for fractals to get contributions from developers they either have to pay them or they at least have to not mess with the equation in the public goods funding model. In other words, if a fractal cannot pay developers it cannot tell developers what to build. But fractals do have the power to provide something that developers need - a signal of recognition (an evaluation) for their work. Fractals can issue that signal in multiple ways: through the usage of their work (onchain transactions), respect game or votes by respect holders. This signal helps developers justify the public goods funding they receive, therefore they have an incentive to build what fractal actually needs. But it should be up to developers to figure out the needs of a fractal rather than fractal telling a developers what to build.\n\nFractals help solve one of the hardest problems in public goods funding - recognition of public goods while having a say in what gets developed through the means that is most natural to them.\n\n## Embracing the competition\nWe often try to be nice and talk in terms of \"how do we collaborate\" and avoid any notion that we are competing. Well, the fact that we avoid talking about competition does not change the fact that it exists. The fact is that a lot of times you have multiple projects working on overlapping features and to say that those projects are not competing for users would be a blatant lie. Competition exists among participants of a fractal either way. But competition does not mean disrespect. Far from it. In sports great competitors have great respect for each other. Fractals have great potential to create great competition while contributing positively to the ecosystem. We should capitalize on that instead of trying to force collaborative development everywhere.\n\n\n[^1]: \"Cathedral and the Bazaar\" by Eric S. Raymond is a great read if you want a more in-depth analysis of Linux-like development process\n",
      "title": "Embracing competition within fractals",
      "author": "sim31",
      "permlink": "embracing-competition-within-fractals",
      "json_metadata": "{\"app\":\"peakd/2024.5.1\",\"format\":\"markdown\",\"description\":\"Group consensus can decide what software to use, but it cannot efficiently decide what software to create\",\"tags\":[\"dao\",\"governance\",\"fractally\",\"consensus\",\"blockchain\",\"optimism-fractal\",\"eden-fractal\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 85450927,
  "trx_id": "cebe4467fe63c7fa82f6a22e72a80e9140bddc07",
  "op_in_trx": 0,
  "timestamp": "2024-05-16T15:48:54",
  "virtual_op": false,
  "trx_in_block": 27
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "orec-s6xvyf"
    }
  ],
  "block": 81936081,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 44,
  "timestamp": "2024-01-15T11:01:09",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment",
    {
      "body": "**Optimistic Respect-based Executive Contract (OREC)** is a smart contract that executes transactions on behalf of a DAO, that has a non-transferrable reputation token (which we call “Respect” here). The main use case is performing code updates of a DAO (if OREC is set as an owner of a proxy contract) but it can be used for other transactions as well.\n\nIt is optimistic because it trusts a minority of contributors who take the initiative to act on behalf of a DAO even if they hold a small amount of Respect. The security comes from a time delay during which other contributors can easily block a transaction if they collectively have a significant enough amount of Respect relative to what the initiators have.\n\n## Mechanism\n\nThe goal is to enable contributors to 1) propose transactions to be executed, 2) vote whether they should be executed, and 3) if they receive enough votes - to execute them.\n\n### Variables\n\n- `stage1_period` = 1 week;\n- `stage2_period` = 1 week;\n- `min_vote_threshold` = 128 Respect;\n- `respect_period` = 12 weeks;\n\n### Process\n\n1. The whole OREC contract goes through cycles, each cycle being composed of 2 stages. At any point in time contract is in one of these 2 stages; \n    1. The first stage is the “voting stage”, where contributors can propose and vote on proposals. It lasts `stage1_period`;\n    2. The second stage is the “blocking” stage, where contributors can block proposals. It lasts `stage2_period`;\n2. Each cycle has a board, which is a set of accounts (board members) that have a weighted vote and the ability to propose transactions;\n3. A vote is weighted by the amount of Respect earned by an account over the last `respect_period`;\n4. The total weight of a board is the sum of the vote weights of all the board members;\n5. To become a member of a board an account has to submit a transaction to register onchain. Registrations hold only for the current cycle.\n6. During the “voting stage” of a cycle, the contract allows:\n    1. Accounts to register to be members of the board of the current cycle;\n    2. Members of the current board to propose transactions (make proposals);\n    3. Members of the current board to vote on proposals;\n7. During the “blocking” stage of a cycle, the contract allows only to register to be members of the board of the current cycle (does not allow making proposals or voting on them);\n8. A proposal can be executed if at the end of a cycle it satisfies the following requirements:\n    1. It has received more than `min_vote_threshold` worth of votes;\n    2. The total weight of approval votes constitute more than 2/3rds of the total weight of a board;\n\n## Rationale\n\nThe effect of the fact that in the 2nd stage, accounts can only register to be board members but not vote (approve) proposals means that in the 2nd stage, proposals can be blocked. This can be done simply by registering to be a board member, because it increases the total weight of a board, which increases the amount of vote weight required to pass proposals, thus potentially un-approving some proposals that might have had enough votes in stage 1. This creates a flexible system where most contributors won’t need to bother with voting for proposals and execution as long as they consent to the transaction proposals being passed.\n\nTypically organizations need to elect people who represent them in doing administrative tasks (like making transactions), which adds overhead. This mechanism avoids that. Anyone who has some Respect can take the initiative. The rest of the community has at least 1 full week (by default parameters) to block anything they don’t like or simply do not have time to review. To block you don’t need to vote against, you simply register. Here having a perspective that proposal needs more review is a perfectly valid reason to block it. Contributors who want to protect their DAO and be part of any executive decision-making can simply register every cycle to be part of the board and only vote for what they are sure of. Registration during a cycle simply signals - “I’m online this cycle and willing to participate in executive decision making. Don’t execute anything without counting my vote.”\n\nThe requirement to register for every cycle ensures that DAO does not get stuck because of people who signaled membership a while ago but are not actively participating in governance anymore. Or people who have a lot of Respect, but don’t have the time or the knowledge necessary to review and execute transactions.\n\nThe DAO can still be “maliciously” blocked by members who hold enough Respect. But this is up to Respect distribution process to prevent that. If Respect distribution represents reality this should not be an issue: if blocking made by some member is perceived as counterproductive that member should receive less Respect [^1]. Vote weight is computed only from the last `respect_period`, so given enough time vote weight should shrink for contributors who are blocking too much or who approve too much according to the rest of a DAO.\n\n---\n[^1]: In fractally-style communities this is achieved using [Respect Game](https://optimystics.io/respectgame)\n",
      "title": "OREC",
      "author": "sim31",
      "permlink": "orec-s6xvyf",
      "json_metadata": "{\"app\":\"peakd/2023.11.3\",\"format\":\"markdown\",\"description\":\"Optimistic Respect-based Executive Contract (OREC) . Execute transactions on behalf of a DAO without election overhead.\",\"tags\":[\"governance\",\"dao\",\"fractally\",\"eden\",\"consensus\",\"blockchain\",\"democracy\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "governance"
    }
  ],
  "block": 81734920,
  "trx_id": "627586d88bd677a346e97879abeae15f93259d39",
  "op_in_trx": 0,
  "timestamp": "2024-01-08T11:01:12",
  "virtual_op": false,
  "trx_in_block": 24
}

{
  "op": [
    "transfer",
    {
      "to": "sim31",
      "from": "howo",
      "memo": "Hey @sim31 I am launching a new solo witness and am looking for support. If you are unfamiliar with what I do, I wrote a post announcing my witness here: https://peakd.com/witness/@howo/annoucing-my-solo-witness. The tl;dr is that I've been on Hive for 6 years and for the past 4 I've been working as a core developer meaning I'm working directly on the blockchain code to add features. You might have interacted with some of them already like RC delegations, recurrent transfers or more recently I've been working on updating communities (new update soon !). If you want to support me, could you vote for me as a witness ? You can do it on this page https://peakd.com/me/witnesses. Thank you !",
      "amount": "0.002 HIVE"
    }
  ],
  "block": 80621462,
  "trx_id": "8159fdb350c6d13519330bc02eec05914399ea30",
  "op_in_trx": 0,
  "timestamp": "2023-11-30T18:24:27",
  "virtual_op": false,
  "trx_in_block": 16
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "higher-order-fractal"
    }
  ],
  "block": 79773022,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 8,
  "timestamp": "2023-11-01T06:40:45",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "sim31",
      "author": "sim31",
      "weight": 8189969723,
      "rshares": 8189969723,
      "permlink": "higher-order-fractal",
      "pending_payout": "0.005 HBD",
      "total_vote_weight": 13060611337
    }
  ],
  "block": 79583905,
  "trx_id": "922ffedbee4fc4a63b966beff094f0e2a3ad9204",
  "op_in_trx": 1,
  "timestamp": "2023-10-25T16:57:03",
  "virtual_op": true,
  "trx_in_block": 39
}

{
  "op": [
    "vote",
    {
      "voter": "sim31",
      "author": "sim31",
      "weight": 10000,
      "permlink": "higher-order-fractal"
    }
  ],
  "block": 79583905,
  "trx_id": "922ffedbee4fc4a63b966beff094f0e2a3ad9204",
  "op_in_trx": 0,
  "timestamp": "2023-10-25T16:57:03",
  "virtual_op": false,
  "trx_in_block": 39
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "joeyarnoldvn",
      "author": "sim31",
      "weight": 476254863,
      "rshares": 476254863,
      "permlink": "higher-order-fractal",
      "pending_payout": "0.002 HBD",
      "total_vote_weight": 4870641614
    }
  ],
  "block": 79571705,
  "trx_id": "36df5c468c097ab7e3fc2b96eb606c691ebaf4a7",
  "op_in_trx": 1,
  "timestamp": "2023-10-25T06:46:18",
  "virtual_op": true,
  "trx_in_block": 27
}

{
  "op": [
    "vote",
    {
      "voter": "joeyarnoldvn",
      "author": "sim31",
      "weight": 147,
      "permlink": "higher-order-fractal"
    }
  ],
  "block": 79571705,
  "trx_id": "36df5c468c097ab7e3fc2b96eb606c691ebaf4a7",
  "op_in_trx": 0,
  "timestamp": "2023-10-25T06:46:18",
  "virtual_op": false,
  "trx_in_block": 27
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 4394386751,
      "rshares": 4394386751,
      "permlink": "higher-order-fractal",
      "pending_payout": "0.001 HBD",
      "total_vote_weight": 4394386751
    }
  ],
  "block": 79571702,
  "trx_id": "ca7de8d5ab65a91a75871e796c849a345e830cd0",
  "op_in_trx": 1,
  "timestamp": "2023-10-25T06:46:09",
  "virtual_op": true,
  "trx_in_block": 20
}

{
  "op": [
    "vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 10000,
      "permlink": "higher-order-fractal"
    }
  ],
  "block": 79571702,
  "trx_id": "ca7de8d5ab65a91a75871e796c849a345e830cd0",
  "op_in_trx": 0,
  "timestamp": "2023-10-25T06:46:09",
  "virtual_op": false,
  "trx_in_block": 20
}

{
  "op": [
    "comment",
    {
      "body": "@@ -1337,94 +1337,30 @@\n the \n-%5BDesign%5D(https://www.notion.so/Design-ea8a6aadf02a455cb21f936a1b0a4d56?pvs=21)\n+%22Design%22\n  section\n+ below\n . Bu\n@@ -7715,17 +7715,16 @@\n em (see \n-%5B\n Motivati\n@@ -7737,84 +7737,10 @@\n tion\n-%5D(https://www.notion.so/Motivation-c18cfb5756de4a11b0263e89ca375ccb?pvs=21)\n )\n+.\n %0A%0AFu\n@@ -14346,102 +14346,16 @@\n her \n-%5B\n benefits\n-%5D(https://www.notion.so/Higher-order-fractal-6b784976920042829a6fdbf55af2199a?pvs=21)\n , th\n",
      "title": "Higher-order fractal",
      "author": "sim31",
      "permlink": "higher-order-fractal",
      "json_metadata": "{\"app\":\"peakd/2023.10.1\",\"format\":\"markdown\",\"description\":\"A fractal with DAOs as members instead of individuals\",\"tags\":[\"governance\",\"dao\",\"fractally\",\"eden\",\"consensus\",\"blockchain\",\"democracy\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "governance"
    }
  ],
  "block": 79571686,
  "trx_id": "3eb29a7ee9586c414e0253f702eebc8f19864f48",
  "op_in_trx": 0,
  "timestamp": "2023-10-25T06:45:21",
  "virtual_op": false,
  "trx_in_block": 5
}

{
  "op": [
    "comment",
    {
      "body": "With more and more fractal-like DAOs springing up, I think it is time to start thinking about how these fractals could interact and organize among each other. Here I will propose one obvious model, which uses a concept of what I think could be called “a higher-order fractal”.\n\n## Introduction\n\nIn mathematics, a higher-order function is a function that either takes functions as arguments or returns a function. In other words - it is a function that deals with functions instead of just variables. In the same vein, **a higher-order fractal would be a fractal composed of fractals or other kinds of DAOs instead of individuals.**\n\nThis creates a fractal pattern, so obviously, it does seem like a natural solution for organizations called “fractals”, but it does raise some critical questions about how meetings and consensus process of this higher-order fractal would work.\n\nIn summary, I suggest that higher-order fractal can simply use the same Respect game and top-contributor-based consensus process as some existing fractals use, except the people participating in meetings would be representatives of DAOs (1 representative per DAO) and Respect would be awarded to a whole DAO. Consensus meetings of higher-order fractal should happen less often and there might be some additional small changes needed. I try to cover those in the [Design](https://www.notion.so/Design-ea8a6aadf02a455cb21f936a1b0a4d56?pvs=21) section. But first, let’s talk about why we might want this.\n\n## Motivation\n\nRespect game at the core of a fractal process, is a very straightforward way to create a common ground for all the DAOs, without much organizational complexity (which would be hard considering we are talking about DAOs organizing not individuals). This common ground can have the following benefits.\n\n### Means to measure performance of different consensus processes / governance solutions\n\nWe have already noticed that each new fractal often mutates a little in its processes. Some fractals make bigger changes, some smaller, but creators of a new fractal almost always put their twist on it. Plus you have kindred DAOs like Upscale (former Eden) and other DAO ecosystems which share a lot of common values with fractals (like [Hypha](https://hypha.earth/) DAOs).\n\nAll this variety is very healthy for the ecosystem. We don’t know which processes are the best, but through this variety of experiments, we create data that can be used to compare all of these different governance workflows.\n\nThis is where this higher-order fractal can be invaluable. One periodic meeting where each DAO presents their progress and then reaches consensus on rankings among themselves can create a very crucial data point for comparison of DAOs and their processes. Not to mention that rankings and Respect distribution that these meetings will output, will by themselves be a very interesting and telling metric.\n\n### Contributor presentations will get a lot more interesting and valuable\n\nIt’s one thing to listen to a presentation of what an individual did throughout one week, it’s whole another thing to listen to what a group of people did in a month or a couple of months. While the former typically just talks about an in-progress work being done, the latter can become a demo of an actual product of that work. This will provide useful content for what these communities are achieving that is meaningful to an outsider and not just old participants.\n\nIt is also easier to evaluate and compare products of work rather than promises of effort being spent. By extending time between meetings and allowing groups of people to be represented we will move towards presentations of products rather than effort.\n\n### Opportunity for smaller DAOs to get seen, get reputation, and attract more people and funding\n\nHigher-order fractal creates an opportunity for positive collaborations of people to get noticed and get reputation. Reputation can lead to other great things for a DAO like new members and potential funding.\n\n### Competition and collaboration between DAOs\n\nThis I think can be a motivating factor for contributors. Higher-order fractal meetings will add more meaning to work performed by individuals in the sub-DAOs because it will add up to something bigger that will be recognized and evaluated at the end of the period.\n\nIt will also create opportunities for DAOs to learn more about each other and collaborate.\n\n## Design\n\nThe core of higher-order fractal would be Respect game like in the typical fractals we know of. But instead of individuals competing for Respect we want to have fractals. For this we need fractals to be able to:\n\n1. Present contributions;\n2. Build consensus with other fractals on the rankings of contributor fractals;\n\nThe simplest solution is to have each fractal elect a representative. This I think should work perfectly for solving the first (presenting contributions). It would be individuals presenting contributions but they would be presenting contributions of a whole fractal instead of just theirs.\n\nFor the second, I think representative is not enough because, while you can prepare a presentation that presents the work of the whole fractal, you can’t really prepare for a consensus process on rankings where you would represent your whole fractal (its opinion on the rankings). Therefore, I think that after all participant DAOs present their contributions, they should be given at least a week to build consensus on their rankings. This will provide time for fractals to discuss the performance of each contributor fractal internally, within their own fractal. The final consensus would still have to be signalled by representatives of each DAO, so that there’s a clear point of contact from each fractal which allows consensus building among fractals.\n\nSo from a representative's perspective, consensus building could be a 3 step process:\n\n1. Poll his fractal for their opinion of how all the contributor fractals should be ranked;\n2. Negotiate and build consensus with representatives of other fractals (who are presumably doing the 1st step as well);\n3. Signal consensus pre-agreed among representatives;\n\nIf representatives do not properly represent their fractal (do not do the first step for example), it is up to that fractal to solve that issue internally and elect a better representative for the next higher-order fractal meeting.\n\nThere are some other changes and considerations to the fractal process we might want to take into account.\n\n### More time in between meetings\n\nConsidering that the overhead required to reach consensus (even through representatives) is bigger in the higher-order fractal, meetings should happen less often than a typical 1 week. Plus each participant DAO usually has its own weekly meetings as well. At least 1 month in between higher-order fractal meetings would be more appropriate but an even bigger gap might be sensible as well. This will give more time for fractals to make something happen, which will make their contributions more interesting.\n\n### More time for the presentation of each DAO\n\nSince each representative will be presenting contributions of the whole group, over a period longer than 1 week, I think they should be given more time to present. Currently, I think the typical time for each to present ranges between 3-5 minutes. For higher-order fractal, 10 minutes might be more appropriate. The time given to break-out groups should be extended as needed.\n\n### Any kind of DAO should be allowed to participate even if it does not follow a fractally-like process\n\nAs long as they present a required interface (i.e.: elect representatives) I don’t see a reason for higher-order fractal to not include them. A variety of different competing consensus processes is good for the ecosystem (see [Motivation section](https://www.notion.so/Motivation-c18cfb5756de4a11b0263e89ca375ccb?pvs=21))\n\nFurthermore, I would consider allowing 1 person DAOs to participate. This can be useful when a person is starting a project and has plans to accept community contributions to his project but has none yet. Then it makes sense for him to create a fractal that would eventually attract contributors. Meanwhile, he would still have a place to present his contributions regarding the project he wants to work on in higher-order fractal meetings. However, it is important that each DAO should be evaluated by the same standards regardless of its size. So 1 person DAO should normally not be able to compete with larger DAOs (assuming those larger DAOs are doing useful work).\n\nParticipants of a higher-order DAO should try to evaluate its sub-DAOs primarily based on their output and not their internal structure. This respects the autonomy of each DAO, which I think is necessary (considering we are talking about decentralized *autonomous* organizations). This is kind of like having some base respect for the privacy of another person’s mind (their beliefs and opinions) as long as the person acts in a socially acceptable manner.\n\nI would make a proposition that bad governance processes would always eventually reflect in the outputs of a DAO. For example, if some sub-DAOs have a governance process that does not respect their members, eventually those members will leave and join other DAOs, which will eventually reflect in the output of that DAO and their rankings in higher-order fractal.\n\n### Higher-order fractal needs a consensus process\n\nSince we are giving more time for presentations (so meetings will take longer), and consensus building among fractals will be slightly more complex, it might make sense to be more careful regarding who participates. Higher-order fractal needs a consensus process for adding (or at least removing) participating DAOs if nothing else. Another reason a consensus process might be needed is the scheduling of meetings.\n\nI don’t think [Eden+Fractal](https://edencreators.com/plus) is suitable here because it adds another consensus problem (electing a delegate fractal) and as already mentioned these consensus problems cost even more in higher-order fractal. Therefore, a top-contributor-based process[^1] would probably be more suitable. This means, however, that we will have to agree on a way by which each of the top fractals signal their approval of a proposal. Again, the question of what mechanism is used for participant DAO to decide to issue this signal is up to each participant DAO to determine.\n\n### Should people be allowed to participate (contribute to) multiple participant DAOs?\n\nGenerally when you have teams competing you don’t allow members of teams to overlap. So it would be natural to expect that being a member of multiple participant DAOs should not be allowed by the higher-order fractal. Plus competition might be more interesting this way. However, actually enforcing this would add a lot of complexity to the system and I would argue that we don’t have much to lose by allowing this.\n\nThe complexity that enforcement of this rule would add would be a bad kind of complexity where higher-order fractal would have to influence the inner structure (membership list) of a sub-DAO (which means infringement on the autonomy of a DAO). Not to mention that any complexity in higher-order DAO is very costly since changing any of the rules will require consensus from all participant DAOs.\n\nOne of the things that could happen if we allow participation in multiple sub-DAOs is that some contribution of a single individual ends up being claimed by multiple sub-DAOs. But then it simply means that these contributions “cancel out” when comparing these two DAOs.\n\nIf some contributor is contributing different things to different DAOs (helping them both), then it means that he is splitting his time and that reflects a certain amount of respect for both DAOs. It means that both DAOs are doing something right because they are attracting contributors.\n\nAnother argument against allowing participating in multiple sub-DAOs is that it would allow people to play dirty by sabotaging competitor DAOs from within. But this can be ascribed to be a problem of individual sub-DAOs as opposed to a problem of higher-order fractal. There are multiple things a DAO could do to protect from sabotage at a local level: \n\n- Transparency regarding who the members are - if members of a DAO are not anonymous then they would have to risk their reputation by trying to sabotage;\n- Review process for contributions (which is already being done to some extent in fractally-like DAOs) could catch any malicious contributions;\n- A good DAO should allow space for members to question the honesty of other members;\n- A DAO could (and probably should) have a mechanism for kicking out members who are malicious (detected to be sabotaging);\n- Simply not allowing people to participate if there's evidence of them participating in other DAOs;\n\nIt’s up to each DAO to decide what methods they apply. If a participant DAO fails to protect itself then it is useful information when evaluating its process and comparing it with other DAOs. Plus a higher-order fractal will not be able to protect from all cases of malicious behaviour. So DAOs will need to think about protection mechanisms for themselves anyway and I think it will be more useful for higher-order fractal to evaluate those mechanisms instead of enforcing them.\n\nSo my preliminary answer is that higher-order fractal should not have a rule against allowing people to participate in multiple DAOs even if those DAOs are competing in a higher-order fractal.\n\n## Conclusion\n\nDAOs / fractals can gain a lot of benefits from organizing into a kind of DAO of DAOs. Here I propose one model for that which I call “higher-order fractal”.\n\nThe guiding principle behind higher-order fractal model is that the DAO that encompasses other DAOs should make a conceptual leap where its participants are smaller DAOs instead of individuals. This will give it a legitimate claim to be called DAO of DAOs. Other than that this DAO should mirror the design of a normal DAO composed of individuals as much as possible. This will make the system simpler and composable.\n\nI propose that this DAO of DAOs should mirror the structure of a typical fractal because it seems like the most natural way to create that kind of DAO. Think of it like a periodic conference for the ecosystem of DAOs, except besides just presenting their progress they would also be playing a game to rank each other's progress. Besides providing many other [benefits](https://www.notion.so/Higher-order-fractal-6b784976920042829a6fdbf55af2199a?pvs=21), this simple game enables bootstrapping a whole higher-level governance process without requiring founder DAOs to agree on any sort of complex ruleset upfront.\n\n\n[^1]: E.g.: top 6 contributor DAOs over the last N meetings have votes in approving proposals, where you need 4/6 votes in order to pass a proposal.\n",
      "title": "Higher-order fractal",
      "author": "sim31",
      "permlink": "higher-order-fractal",
      "json_metadata": "{\"app\":\"peakd/2023.10.1\",\"format\":\"markdown\",\"description\":\"A fractal with DAOs as members instead of individuals\",\"tags\":[\"governance\",\"dao\",\"fractally\",\"eden\",\"consensus\",\"blockchain\",\"democracy\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "governance"
    }
  ],
  "block": 79571595,
  "trx_id": "3cd69cb306140c102763c126120f6325f18a4e35",
  "op_in_trx": 0,
  "timestamp": "2023-10-25T06:40:48",
  "virtual_op": false,
  "trx_in_block": 26
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "respect-trees"
    }
  ],
  "block": 79511695,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2023-10-23T04:42:21",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 4820851148,
      "rshares": 4820851148,
      "permlink": "respect-trees",
      "pending_payout": "0.001 HBD",
      "total_vote_weight": 4820851148
    }
  ],
  "block": 79310468,
  "trx_id": "a4a7b9323fba878c3cbc82476ddafaeda6fe7329",
  "op_in_trx": 1,
  "timestamp": "2023-10-16T04:51:27",
  "virtual_op": true,
  "trx_in_block": 20
}

{
  "op": [
    "vote",
    {
      "voter": "bluesniper",
      "author": "sim31",
      "weight": 10000,
      "permlink": "respect-trees"
    }
  ],
  "block": 79310468,
  "trx_id": "a4a7b9323fba878c3cbc82476ddafaeda6fe7329",
  "op_in_trx": 0,
  "timestamp": "2023-10-16T04:51:27",
  "virtual_op": false,
  "trx_in_block": 20
}

{
  "op": [
    "comment",
    {
      "body": "\nRespect tree is a primitive that can be used by a fractal with non-transferrable Respect to: \n\n- Organize thoughts of a group of people;\n- Help track and determine priority of:\n    - Topics to discuss;\n    - Goals / tasks to pursue;\n    - Questions to research / answer;\n    - Issues to solve;\n    - Projects to develop;\n- Validate and select solutions;\n\nAll of this using a single smart contract that implements a simple tree data structure, where nodes are weighted by Respect votes.\n\nEach node has the following attributes: \n\n- Name\n- Tag (question, answer, issue, solution) (optional)\n- Short description (optional)\n- IPFS link (optional)\n- Total weight;\n- Author account;\n- Balance table (weight per account, should sum to total weight);\n\nThe root node has a total weight equal to the current supply of Respect of a fractal (Respect is assumed to be non-transferrable). The balance table of the root node is the balance table of Respect.\n\nAnyone can create a child node for any node.\n\nAny account with non-zero Respect can vote on the child node. They can choose the amount of Respect to vote with. They can vote for multiple child nodes. The total Respect distributed by an account to the child nodes must not be more than the balance of that account in the parent node.\n\nThe account balance in the child node is equal to the Respect votes for that node by that account.\n\n## Example\n\n\n![respect-tree.drawio.png](https://files.peakd.com/file/peakd-hive/sim31/23tHbr9ykeZbvCosdZP4s2sx2h71UFBiinTtqvAEYE5oFVnRpxFvxCmKvqvYktzKw6Qv1.png)\n\n\n[https://drive.google.com/file/d/1LXOjoQXjEkIdp9MZmXmgwTjvtdst6qn8/view?usp=sharing](https://drive.google.com/file/d/1LXOjoQXjEkIdp9MZmXmgwTjvtdst6qn8/view?usp=sharing)\n\n## Bounty system\n\nContributors can deploy smart contracts which collect tokens that can be released on condition: \"if node X in respect tree received certain threshold of Respect then, allow the owner of the contract take the funds out. Else if a deadline passes without X receiving the threshold, then allow the sender of funds to claim them back\". When node X is a project that is a solution to an issue/task in a respect tree then fractal acts as a validator of solutions in a bounty system.\n\nThe difference from a typical bounty system is that the validator and creator of issues is not necessarily the same as the funding source and that validation of a solution to a bounty is controlled by respected members of a democratic process.\n\n# Questions\n\n## 1. Why tree and not a graph?\n\nA graph is a more general structure, where nodes can contain multiple parents, instead of just one like in a tree here. Total weight of a node could be sum of votes coming from its parents.\n\nOverall, intuitively it seems to me that tree structure is simpler and might put constraints which can actually be useful for organization. Bellow is some of my reasoning, justifying a choice of a tree.\n\nLet's take concrete examples.\n\n### 1.1. Same project / solution idea / solution solving multiple issues\n\nSame project could solve multiple issues. This makes it seem that 'project' node should have multiple parents. However aren't we losing useful information this way? People who come to vote on a project node through one issue might see that project only as means to solve that one issue they care about. They might not care about other issues that the project claims to be solving. But if votes coming from different parents are summed, this information is not preserved - it is not clear which motivation (parent issue) is stronger. And this motivation coming from the parent issue is important - it should influence the priorities within the project.\n\nA better solution might be for nodes to contain links to other nodes. Project node could be placed somewhere higher up the tree and link nodes could be put under some of the issues it addresses, but they would not add weight to the project node (except by people following the link and redistributing their respect manually).\n\n### 1.2. Same question under multiple projects / issues.\n\nThe parent node in this case would define context for the question and answer. The same question statement might require different answers depending on context and parent nodes define context.\n\nSo same question node under multiple parents could be misleading… It could lead people to accepting answers to questions even though they only address one context out of multiple they should be addressing.\n\n-----------\n\n*Original post in Notion*: https://adaptable-oxygen-176.notion.site/Respect-tree-1d34a791bc3f4538a44171707ce77d79?pvs=4",
      "title": "Respect trees",
      "author": "sim31",
      "permlink": "respect-trees",
      "json_metadata": "{\"app\":\"peakd/2023.10.1\",\"format\":\"markdown\",\"description\":\"A primitive to help community with non-transferable reputation token to organize their thoughts\",\"tags\":[\"governance\",\"dao\",\"fractally\",\"eden\",\"consensus\",\"blockchain\"],\"users\":[],\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23tHbr9ykeZbvCosdZP4s2sx2h71UFBiinTtqvAEYE5oFVnRpxFvxCmKvqvYktzKw6Qv1.png\"]}",
      "parent_author": "",
      "parent_permlink": "governance"
    }
  ],
  "block": 79310287,
  "trx_id": "1a5b2edde2a6bfaee0fe1a928e5eb61d539d4fe7",
  "op_in_trx": 0,
  "timestamp": "2023-10-16T04:42:24",
  "virtual_op": false,
  "trx_in_block": 19
}

{
  "op": [
    "expired_account_notification",
    {
      "account": "sim31"
    }
  ],
  "block": 76907757,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 3,
  "timestamp": "2023-07-24T16:21:18",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "transfer",
    {
      "to": "sim31",
      "from": "howo",
      "memo": "Hi ! I've been a core developer on hive for three years now, working on features that are now powering the chain and improving user experience like RC delegations or recurrent transfers and currently wrapping up some features that will go live in hard fork 27. I'm also hosting the monthly core dev meeting. I would like to carry on working for hive for a fourth year. I am looking for support on my renewed proposal as the current one will expire soon. It's the same deal as the last one. Could you review it and maybe vote on it if it's worth your support ? https://peakd.com/me/proposals/261 Thanks a lot !",
      "amount": "0.001 HBD"
    }
  ],
  "block": 74233261,
  "trx_id": "44676eeb9f14d094ebdef1af7a798cb80f016627",
  "op_in_trx": 0,
  "timestamp": "2023-04-22T16:27:33",
  "virtual_op": false,
  "trx_in_block": 42
}

{
  "op": [
    "comment",
    {
      "body": "\nhttps://reddit.com/r/eos/comments/11xio98/recaps_eden_fractal_tuesday_20230321/\n<sub> The rewards earned on this comment will go directly to the people sharing the post on Reddit as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.</sub>",
      "title": "",
      "author": "redditposh",
      "permlink": "re-sim31-introducing-fractalgram-2067",
      "json_metadata": "{\"app\":\"Poshtoken 0.0.2\",\"payoutToUser\":[]}",
      "parent_author": "sim31",
      "parent_permlink": "introducing-fractalgram"
    }
  ],
  "block": 73320751,
  "trx_id": "9c19c8db06203d99e403c8e487c108d17afee78f",
  "op_in_trx": 0,
  "timestamp": "2023-03-21T22:53:36",
  "virtual_op": false,
  "trx_in_block": 27
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "inherent-conflict-in-defining-mission-statements-for-a-democratic-organization"
    }
  ],
  "block": 72908618,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 62,
  "timestamp": "2023-03-07T15:05:30",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "vote",
    {
      "voter": "sim31",
      "author": "thiagorewards",
      "weight": 10000,
      "permlink": "fractalgram-a-tool-to-facilitate-fractal-consensus-building-on-eos"
    }
  ],
  "block": 72708531,
  "trx_id": "556b0d215120fe61a40cdea7c300937f6571db3b",
  "op_in_trx": 0,
  "timestamp": "2023-02-28T16:09:48",
  "virtual_op": false,
  "trx_in_block": 24
}

{
  "op": [
    "comment",
    {
      "body": "Consider some hypothetical organization. Let's say it has a clear mission statement and it also claims to be a true democracy, empowering the individual. What happens if individual participants of this organization start disagreeing with the mission (purpose) of an organization? Well, if it's a democracy, people should be able to change the mission of their organization, right? On the other hand, if we do this, we would be changing what this organization is, and proponents of its old purpose might feel betrayed. This is especially true if we define an organization by its mission, as is often done.\n\nIn a democratic organization there are two sources of intent from which everything else flows down:\n* Mission/vision, as expressed by the creators or participants of an organization;\n* Voice of the people (better, yet, consensus of the people);\n\nWhat happens when these two sources start conflicting? Do we kick out the people who don't serve the mission anymore or do we change the mission? If we are talking about an organization, which is easy to join, this conflict becomes even more likely, because churn in the set of participants, might mean changes in the consensus opinion about what the mission of the organization should be.\n\nUltimately, what we are talking about is a set of values, one of them being a democracy, and the other being the goal as expressed by the mission statement. Organization needs to decide which of these is higher in its hierarchy of values.\n\nAnother option is to define a mission that would be more or less equivalent to democratic ideals. For example, if an organization claims that its mission is to listen to its participants and empower them by implementing their will as expressed by their consensus, then the mission statement of such an organization is basically saying that its purpose is to be democratic for its participants. So the conflict is avoided because the mission is made equivalent to the goal of being democratic.",
      "title": "Inherent conflict in defining mission statements for a democratic organization",
      "author": "sim31",
      "permlink": "inherent-conflict-in-defining-mission-statements-for-a-democratic-organization",
      "json_metadata": "{\"app\":\"peakd/2023.2.2\",\"format\":\"markdown\",\"description\":\"Listen to participants and change the mission, or stick to the mission and change participants?\",\"tags\":[\"dao\",\"democracy\",\"consensus\",\"eden\",\"fractally\",\"blockchain\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 72707247,
  "trx_id": "8915fad18920fd0f15c02a5ab4fdb267579381d0",
  "op_in_trx": 0,
  "timestamp": "2023-02-28T15:05:33",
  "virtual_op": false,
  "trx_in_block": 138
}

{
  "op": [
    "comment_benefactor_reward",
    {
      "author": "thiagorewards",
      "permlink": "thiagore-is-launched",
      "benefactor": "sim31",
      "hbd_payout": "0.053 HBD",
      "hive_payout": "0.000 HIVE",
      "vesting_payout": "229.176777 VESTS",
      "payout_must_be_claimed": true
    }
  ],
  "block": 72363460,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 25,
  "timestamp": "2023-02-16T16:18:09",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "custom_json",
    {
      "id": "peakd_notify",
      "json": "{\"action\":\"markAsRead\",\"date\":\"2023-02-14T16:16:06\"}",
      "required_auths": [],
      "required_posting_auths": [
        "sim31"
      ]
    }
  ],
  "block": 72305917,
  "trx_id": "c72ae351e541cc66bcc41cf81e811dd22b94032b",
  "op_in_trx": 1,
  "timestamp": "2023-02-14T16:18:06",
  "virtual_op": false,
  "trx_in_block": 72
}

{
  "op": [
    "custom_json",
    {
      "id": "notify",
      "json": "[\"setLastRead\",{\"date\":\"2023-02-14T16:16:06\"}]",
      "required_auths": [],
      "required_posting_auths": [
        "sim31"
      ]
    }
  ],
  "block": 72305917,
  "trx_id": "c72ae351e541cc66bcc41cf81e811dd22b94032b",
  "op_in_trx": 0,
  "timestamp": "2023-02-14T16:18:06",
  "virtual_op": false,
  "trx_in_block": 72
}

{
  "op": [
    "comment_options",
    {
      "author": "thiagorewards",
      "permlink": "thiagore-is-launched",
      "extensions": [
        [
          0,
          {
            "beneficiaries": [
              {
                "weight": 2500,
                "account": "dan"
              },
              {
                "weight": 2500,
                "account": "sim31"
              },
              {
                "weight": 2500,
                "account": "soushi888"
              }
            ]
          }
        ]
      ],
      "allow_votes": true,
      "percent_hbd": 10000,
      "max_accepted_payout": "1000000.000 HBD",
      "allow_curation_rewards": true
    }
  ],
  "block": 72162186,
  "trx_id": "2b9f5b5da13888c9ea3280bcaef3de791a771681",
  "op_in_trx": 1,
  "timestamp": "2023-02-09T16:18:12",
  "virtual_op": false,
  "trx_in_block": 0
}

{
  "op": [
    "comment",
    {
      "body": "@@ -6003,9 +6003,99 @@\n NDJk .%0A%0A\n+If you want to check out the source code, it is here: https://github.com/sim31/fractalgram\n %0A\n",
      "title": "Introducing - Fractalgram!",
      "author": "sim31",
      "permlink": "introducing-fractalgram",
      "json_metadata": "{\"app\":\"peakd/2023.1.1\",\"format\":\"markdown\",\"description\":\"Fractalgram is an alternative telegram client web app tailored to help host fractally or Eden style consensus meetings.\",\"tags\":[\"dao\",\"consensus\",\"fractally\",\"governance\",\"eden\",\"telegram\",\"blockchain\"],\"users\":[],\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23sdvSk3uJg19fhSwFuXSGtnca5b7QictWKQNFa3d8EJnCRQuhXPaMqsTc8kB9YDeNsdo.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23z7WqY4pzfSMhFM8rELb2Ae5RL9SSu6iwo1gjSfxczdcuN1qPZAY5dBzortNAoMZufre.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zSJ16NSiTAavirJQeHDYCpXGMdYqeEL8FAJTum7atqYYbVD9CPpqWLyUnYD3WAYAJf1.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/2424AHwDNC1Rk832LG6w8XMDK5fRYsSwtoNnfmcH4uEBFVSFbaq9baQJpfWKBFnRpGuZX.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgNZ9hLmwrHbxqMXxUYxk8yGXkcP18mskym5n8htCQTJevomn2tezCNez.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgP3cH9BcjPVUmcbeS3YfJH3477UraBQ1uERnmxNxH4dwXMU4amunxv7j.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zm3B3dxsYF1U1A6qV1TthZDNh8GKDtZEwVDDKdaKB49WNMKfU1ZwaWaBMxQ95XqvRkC.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/EpXNMU6uD716UVs3NdD2HJk9zbim55oapKrvxXquqwMZ6Z7BVDcE17Q11mLmuJFnBdY.gif\"]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 72135498,
  "trx_id": "26cb0bd66315059825434986a4c33924eb231c88",
  "op_in_trx": 0,
  "timestamp": "2023-02-08T18:02:03",
  "virtual_op": false,
  "trx_in_block": 23
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "sim31",
      "author": "douglasjames",
      "weight": 8189969723,
      "rshares": 8189969723,
      "permlink": "re-sim31-rprvzq",
      "pending_payout": "0.004 HBD",
      "total_vote_weight": 8189969723
    }
  ],
  "block": 72135419,
  "trx_id": "f4d1c5679d929df1f02c3c98dca0f32747b4f830",
  "op_in_trx": 1,
  "timestamp": "2023-02-08T17:58:06",
  "virtual_op": true,
  "trx_in_block": 79
}

{
  "op": [
    "vote",
    {
      "voter": "sim31",
      "author": "douglasjames",
      "weight": 10000,
      "permlink": "re-sim31-rprvzq"
    }
  ],
  "block": 72135419,
  "trx_id": "f4d1c5679d929df1f02c3c98dca0f32747b4f830",
  "op_in_trx": 0,
  "timestamp": "2023-02-08T17:58:06",
  "virtual_op": false,
  "trx_in_block": 79
}

{
  "op": [
    "comment",
    {
      "body": "# Incredible tool, thanks Tadas!!",
      "title": "",
      "author": "douglasjames",
      "permlink": "re-sim31-rprvzq",
      "json_metadata": "{\"tags\":[\"dao\"],\"app\":\"peakd/2023.2.1\"}",
      "parent_author": "sim31",
      "parent_permlink": "introducing-fractalgram"
    }
  ],
  "block": 72135167,
  "trx_id": "8e92e56f0cf65d93bd05b07242ac705dde27400c",
  "op_in_trx": 0,
  "timestamp": "2023-02-08T17:45:30",
  "virtual_op": false,
  "trx_in_block": 73
}

{
  "op": [
    "vote",
    {
      "voter": "douglasjames",
      "author": "sim31",
      "weight": 10000,
      "permlink": "introducing-fractalgram"
    }
  ],
  "block": 72135162,
  "trx_id": "ea2491539c01cd01e5c7f35b3d430925dabefc4c",
  "op_in_trx": 0,
  "timestamp": "2023-02-08T17:45:15",
  "virtual_op": false,
  "trx_in_block": 79
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "introducing-fractalgram"
    }
  ],
  "block": 72125571,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 6,
  "timestamp": "2023-02-08T09:45:03",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment_reward",
    {
      "author": "sim31",
      "payout": "0.022 HBD",
      "permlink": "introducing-fractalgram",
      "author_rewards": 25,
      "total_payout_value": "0.010 HBD",
      "curator_payout_value": "0.010 HBD",
      "beneficiary_payout_value": "0.000 HBD"
    }
  ],
  "block": 72125571,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 5,
  "timestamp": "2023-02-08T09:45:03",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "author_reward",
    {
      "author": "sim31",
      "permlink": "introducing-fractalgram",
      "hbd_payout": "0.005 HBD",
      "hive_payout": "0.000 HIVE",
      "vesting_payout": "23.290790 VESTS",
      "payout_must_be_claimed": true,
      "curators_vesting_payout": "42.998383 VESTS"
    }
  ],
  "block": 72125571,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 4,
  "timestamp": "2023-02-08T09:45:03",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "thiagorewards",
      "author": "sim31",
      "weight": 1900887611,
      "rshares": 15207100893,
      "permlink": "introducing-fractalgram",
      "pending_payout": "0.021 HBD",
      "total_vote_weight": 24748206494
    }
  ],
  "block": 72022811,
  "trx_id": "6ed7c4501ed98c1d834fe49bcc5a804712342615",
  "op_in_trx": 1,
  "timestamp": "2023-02-04T20:00:00",
  "virtual_op": true,
  "trx_in_block": 13
}

{
  "op": [
    "vote",
    {
      "voter": "thiagorewards",
      "author": "sim31",
      "weight": 4000,
      "permlink": "introducing-fractalgram"
    }
  ],
  "block": 72022811,
  "trx_id": "6ed7c4501ed98c1d834fe49bcc5a804712342615",
  "op_in_trx": 0,
  "timestamp": "2023-02-04T20:00:00",
  "virtual_op": false,
  "trx_in_block": 13
}

{
  "op": [
    "comment",
    {
      "body": "@@ -2021,16 +2021,140 @@\n ut room.\n+ You might not be able to add some people because of their privacy settings. You should share a link to the group with them.\n %0A%0A!%5Bcrea\n@@ -2285,24 +2285,128 @@\n eNsdo.gif)%0A%0A\n+**Note: the group will have to have between 3 and 6 members in order to be able to do the next steps.**%0A\n %0A### Step 3:\n",
      "title": "Introducing - Fractalgram!",
      "author": "sim31",
      "permlink": "introducing-fractalgram",
      "json_metadata": "{\"app\":\"peakd/2023.1.1\",\"format\":\"markdown\",\"description\":\"Fractalgram is an alternative telegram client web app tailored to help host fractally or Eden style consensus meetings.\",\"tags\":[\"dao\",\"consensus\",\"fractally\",\"governance\",\"eden\",\"telegram\",\"blockchain\"],\"users\":[],\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23sdvSk3uJg19fhSwFuXSGtnca5b7QictWKQNFa3d8EJnCRQuhXPaMqsTc8kB9YDeNsdo.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23z7WqY4pzfSMhFM8rELb2Ae5RL9SSu6iwo1gjSfxczdcuN1qPZAY5dBzortNAoMZufre.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zSJ16NSiTAavirJQeHDYCpXGMdYqeEL8FAJTum7atqYYbVD9CPpqWLyUnYD3WAYAJf1.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/2424AHwDNC1Rk832LG6w8XMDK5fRYsSwtoNnfmcH4uEBFVSFbaq9baQJpfWKBFnRpGuZX.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgNZ9hLmwrHbxqMXxUYxk8yGXkcP18mskym5n8htCQTJevomn2tezCNez.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgP3cH9BcjPVUmcbeS3YfJH3477UraBQ1uERnmxNxH4dwXMU4amunxv7j.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zm3B3dxsYF1U1A6qV1TthZDNh8GKDtZEwVDDKdaKB49WNMKfU1ZwaWaBMxQ95XqvRkC.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/EpXNMU6uD716UVs3NdD2HJk9zbim55oapKrvxXquqwMZ6Z7BVDcE17Q11mLmuJFnBdY.gif\"]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 71957630,
  "trx_id": "85bff3455a3f505f3e6462636aa4ac3ff2fc3420",
  "op_in_trx": 0,
  "timestamp": "2023-02-02T13:37:27",
  "virtual_op": false,
  "trx_in_block": 47
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "sim31",
      "author": "institutdpos",
      "weight": 8189969723,
      "rshares": 8189969723,
      "permlink": "re-sim31-202321t221146981z",
      "pending_payout": "0.004 HBD",
      "total_vote_weight": 8189969723
    }
  ],
  "block": 71957196,
  "trx_id": "3008ab75bbf5f883b1368dfae0c2c7d78693f392",
  "op_in_trx": 1,
  "timestamp": "2023-02-02T13:15:45",
  "virtual_op": true,
  "trx_in_block": 0
}

{
  "op": [
    "vote",
    {
      "voter": "sim31",
      "author": "institutdpos",
      "weight": 10000,
      "permlink": "re-sim31-202321t221146981z"
    }
  ],
  "block": 71957196,
  "trx_id": "3008ab75bbf5f883b1368dfae0c2c7d78693f392",
  "op_in_trx": 0,
  "timestamp": "2023-02-02T13:15:45",
  "virtual_op": false,
  "trx_in_block": 0
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "institutdpos",
      "author": "sim31",
      "weight": 22847318883,
      "rshares": 22847318883,
      "permlink": "introducing-fractalgram",
      "pending_payout": "0.012 HBD",
      "total_vote_weight": 22847318883
    }
  ],
  "block": 71945144,
  "trx_id": "8f18e406b020e33a2b9164b7da9a0071d9aa72df",
  "op_in_trx": 1,
  "timestamp": "2023-02-02T03:12:30",
  "virtual_op": true,
  "trx_in_block": 59
}

{
  "op": [
    "vote",
    {
      "voter": "institutdpos",
      "author": "sim31",
      "weight": 5000,
      "permlink": "introducing-fractalgram"
    }
  ],
  "block": 71945144,
  "trx_id": "8f18e406b020e33a2b9164b7da9a0071d9aa72df",
  "op_in_trx": 0,
  "timestamp": "2023-02-02T03:12:30",
  "virtual_op": false,
  "trx_in_block": 59
}

{
  "op": [
    "comment",
    {
      "body": "Great tools, looking forward to use it during @thiagorewards council meetings.",
      "title": "",
      "author": "institutdpos",
      "permlink": "re-sim31-202321t221146981z",
      "json_metadata": "{\"tags\":[\"dao\",\"consensus\",\"fractally\",\"governance\",\"eden\",\"telegram\",\"blockchain\"],\"app\":\"ecency/3.0.30-vision\",\"format\":\"markdown+html\"}",
      "parent_author": "sim31",
      "parent_permlink": "introducing-fractalgram"
    }
  ],
  "block": 71945131,
  "trx_id": "fd9e382f2ae4bde586249e21074dbcd3bde42904",
  "op_in_trx": 0,
  "timestamp": "2023-02-02T03:11:51",
  "virtual_op": false,
  "trx_in_block": 20
}

{
  "op": [
    "comment",
    {
      "body": "[Fractalgram](https://fractgram.web.app/) is an alternative telegram client web app tailored to help host fractally or Eden style consensus meetings. \n\nToday I'm introducing the first version of this app. It is still a very early version of the app and there's a lot of room for improvement (especially when it comes to the user experience side of things). But we already tested it in one breakout room during the last EdenFractal meeting and majority of participants agree that this is an improvement over the old method using the zoom chat.\n\nFor now it is geared only towards helping individual breakout rooms (it does not generate breakout rooms or otherwise give additional help in the main room). But in the future, it could be extended to become a standalone tool to host fractally or Eden-style meetings.\n\nIn its current version, the purpose of this app is only to equip participants of a break-out room with tools to make consensus building easier. There's no commitment needed by the fractal to use this app or not - it is up to each breakout room to decide how they build consensus.\n\n## How to use it?\nBreakout rooms, which want to use this tool, have to have at least one participant (let's call him admin of the group) who logs onto https://fractgram.web.app/ using his telegram credentials and administers the consensus building of his break-out room from there. The rest of participants can use their usual telegram clients. Anyone could take the role of the admin, but the process is likely to be smoother if the role is performed by only 1 person instead of multiple.\n\n## Workflow for the admin of the group\nThe rest of this post will describe the workflow from the perspective of admin.\n### Step 1: Log in to fractalgram using your telegram account\nGo to https://fractgram.web.app/ and if you're not logged in there yet, follow the on-screen instructions to do so.\n\n### Step 2: Create a new telegram group\nThis will be a telegram group of your breakout room. Only invite people who belong to your breakout room.\n\n![create-group.gif](https://files.peakd.com/file/peakd-hive/sim31/23sdvSk3uJg19fhSwFuXSGtnca5b7QictWKQNFa3d8EJnCRQuhXPaMqsTc8kB9YDeNsdo.gif)\n\n\n### Step 3: Create an EOS account prompt message\nThis step is only needed if you are planning to submit consensus results to some external platform (like EdenFractal is submitting to EOS).\n\nHover over the \"attachments\" button and choose \"Account prompt\". In the modal that opens you can specify a name of a platform. By default it is EOS, so EdenFractal members can just press send.\n\n![account-prompt.gif](https://files.peakd.com/file/peakd-hive/sim31/23z7WqY4pzfSMhFM8rELb2Ae5RL9SSu6iwo1gjSfxczdcuN1qPZAY5dBzortNAoMZufre.gif)\n\n\n### Step 4: Ask everyone to submit their account names\nEveryone should now reply to the EOS account prompt message submitted previously with their EOS account name. It is important that EOS account name is sent not as a normal message but as a reply.\n\n![reply-to-account-prompt.gif](https://files.peakd.com/file/peakd-hive/sim31/23zSJ16NSiTAavirJQeHDYCpXGMdYqeEL8FAJTum7atqYYbVD9CPpqWLyUnYD3WAYAJf1.gif)\n\nThis step is only needed if you are planning to submit consensus results to some external platform (like EdenFractal is submitting to EOS).\n\nThis step can also be done later but must be done before the results message if you want it to have a link to submit full results.\n\n### Step 5: Create a level 6 poll\nGo to the attachment menu again and select \"Level 6 poll\". In the modal that opens, you can review the poll you are creating and click send.\n\n\n![rank-poll.gif](https://files.peakd.com/file/peakd-hive/sim31/2424AHwDNC1Rk832LG6w8XMDK5fRYsSwtoNnfmcH4uEBFVSFbaq9baQJpfWKBFnRpGuZX.gif)\n\n\n### Step 6: Vote and reach consensus on level 6\nAsk everyone to vote in the poll you just created. The initial vote is not meant to be final. People can switch their vote by right-clicking on the poll, choosing \"retract vote\" and then voting again.\n\n\n![retract-vote.gif](https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgNZ9hLmwrHbxqMXxUYxk8yGXkcP18mskym5n8htCQTJevomn2tezCNez.gif)\n\n\n### Step 7: Repeat steps 5-6 for the remaining levels\nYou don't need to create a poll for the last level if you reached consensus on all the previous. The app will figure out which account remains to be ranked as the last level.\n\n### Step 8: Vote and reach consensus on the delegate\nSelect \"Delegate poll\" in the attachment menu.\n\n\n![delegate-poll.gif](https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgP3cH9BcjPVUmcbeS3YfJH3477UraBQ1uERnmxNxH4dwXMU4amunxv7j.gif)\n\n\n### Step 9: Create results message\nSelect \"Consensus results\" in the attachments menu.\n\nIn the next modal, you can choose where the results should be submitted by participants. Default values are setup for EdenFractal, so if it is EdenFractal meeting, just click \"Next\".\n\nIf you did not select \"None\" in the previous modal, you will be asked for a group number. Enter a group number and click next.\n\nFinally, you will be shown the composed results message which you can customize before submitting. Results are derived from the existing polls in the chat, so should most of the time be correct.\n\n\n![results-message.gif](https://files.peakd.com/file/peakd-hive/sim31/23zm3B3dxsYF1U1A6qV1TthZDNh8GKDtZEwVDDKdaKB49WNMKfU1ZwaWaBMxQ95XqvRkC.gif)\n\n\n### Step 10: Signal consensus\nIf participants of a breakout room agree with the results you posted, they should click the link in the message to submit the results.\n\n\n![consensus-signal.gif](https://files.peakd.com/file/peakd-hive/sim31/EpXNMU6uD716UVs3NdD2HJk9zbim55oapKrvxXquqwMZ6Z7BVDcE17Q11mLmuJFnBdY.gif)\n\n\n## That's it!\nIf you have any comments, questions, feedback, notice any bugs, or want a group to test with, please join me at https://t.me/+AgHQ4qT31qw0NDJk .\n\n\n",
      "title": "Introducing - Fractalgram!",
      "author": "sim31",
      "permlink": "introducing-fractalgram",
      "json_metadata": "{\"app\":\"peakd/2023.1.1\",\"format\":\"markdown\",\"description\":\"Fractalgram is an alternative telegram client web app tailored to help host fractally or Eden style consensus meetings.\",\"tags\":[\"dao\",\"consensus\",\"fractally\",\"governance\",\"eden\",\"telegram\",\"blockchain\"],\"users\":[],\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23sdvSk3uJg19fhSwFuXSGtnca5b7QictWKQNFa3d8EJnCRQuhXPaMqsTc8kB9YDeNsdo.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23z7WqY4pzfSMhFM8rELb2Ae5RL9SSu6iwo1gjSfxczdcuN1qPZAY5dBzortNAoMZufre.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zSJ16NSiTAavirJQeHDYCpXGMdYqeEL8FAJTum7atqYYbVD9CPpqWLyUnYD3WAYAJf1.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/2424AHwDNC1Rk832LG6w8XMDK5fRYsSwtoNnfmcH4uEBFVSFbaq9baQJpfWKBFnRpGuZX.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgNZ9hLmwrHbxqMXxUYxk8yGXkcP18mskym5n8htCQTJevomn2tezCNez.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/242Db96savbETgP3cH9BcjPVUmcbeS3YfJH3477UraBQ1uERnmxNxH4dwXMU4amunxv7j.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/23zm3B3dxsYF1U1A6qV1TthZDNh8GKDtZEwVDDKdaKB49WNMKfU1ZwaWaBMxQ95XqvRkC.gif\",\"https://files.peakd.com/file/peakd-hive/sim31/EpXNMU6uD716UVs3NdD2HJk9zbim55oapKrvxXquqwMZ6Z7BVDcE17Q11mLmuJFnBdY.gif\"]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 71924220,
  "trx_id": "f0d763a1ae1f3cc177748f4c20357656c637c588",
  "op_in_trx": 0,
  "timestamp": "2023-02-01T09:45:06",
  "virtual_op": false,
  "trx_in_block": 2
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "fungibility-out-of-non-fungible-tokens"
    }
  ],
  "block": 68935403,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2022-10-20T12:12:24",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "edenfractal-consensus-process"
    }
  ],
  "block": 68878606,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2022-10-18T12:49:27",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "fractal-blockchains"
    }
  ],
  "block": 68762986,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2022-10-14T12:15:30",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment",
    {
      "body": "@@ -4379,40 +4379,288 @@\n ing \n-to burns of NFTs that deserve it\n+fairly to requests for attention. For example, if there's at least some quality to the content (it is not spam) it should get ranked even if ranking is low. For posts that are not spam a clear and public protocol should be followed for prioritizing posts for which NFTs are burned\n .%0A%0A-\n",
      "title": "Fungibility out of non-fungible tokens",
      "author": "sim31",
      "permlink": "fungibility-out-of-non-fungible-tokens",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"description\":\"A DAO that reaches consensus on the set of NFTs it respects, incentivizes ecosystem to create a fungible token for them\",\"format\":\"markdown\",\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23t8CfKPvTxpigqV5biZSoX13jsqXqjmcBMFx89upigqC1UDbKufF7Nc4KFagv3Hi49Yy.png\"],\"tags\":[\"dao\",\"blockchain\",\"consensus\",\"fractally\"],\"users\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 68735891,
  "trx_id": "68d3f04fe3cc201d638a0874ebd363e0e4f23c64",
  "op_in_trx": 0,
  "timestamp": "2022-10-13T13:36:09",
  "virtual_op": false,
  "trx_in_block": 47
}

{
  "op": [
    "comment",
    {
      "body": "@@ -3946,16 +3946,186 @@\n posts.%0A%0A\n+%0A!%5Bselling-fractal-attention-post1.drawio.png%5D(https://files.peakd.com/file/peakd-hive/sim31/23t8CfKPvTxpigqV5biZSoX13jsqXqjmcBMFx89upigqC1UDbKufF7Nc4KFagv3Hi49Yy.png)%0A%0A%0A\n Of cours\n",
      "title": "Fungibility out of non-fungible tokens",
      "author": "sim31",
      "permlink": "fungibility-out-of-non-fungible-tokens",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"description\":\"A DAO that reaches consensus on the set of NFTs it respects, incentivizes ecosystem to create a fungible token for them\",\"format\":\"markdown\",\"image\":[\"https://files.peakd.com/file/peakd-hive/sim31/23t8CfKPvTxpigqV5biZSoX13jsqXqjmcBMFx89upigqC1UDbKufF7Nc4KFagv3Hi49Yy.png\"],\"tags\":[\"dao\",\"blockchain\",\"consensus\",\"fractally\"],\"users\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 68735342,
  "trx_id": "54c3e45fb3692175b7c1d9e46cf5cfebaad5211a",
  "op_in_trx": 0,
  "timestamp": "2022-10-13T13:08:39",
  "virtual_op": false,
  "trx_in_block": 30
}

{
  "op": [
    "comment",
    {
      "body": "Every dollar bill is unique. And yet we treat them as fungible. Every bitcoin is associated with a unique unspent-transaction-output - every bitcoin is effectively unique. Yet we treat it as fungible as well. These are just a couple of examples of how unique tokens are turned into fungible tokens simply by society having consensus to treat them that way.\n\nA key to making non-fungible token fungible is function/utility. If a set of NFTs has the same utility (and the same amount of that utility), then people will be incentivized to start trading that set of NFTs as if their individual units were fungible. It does not even matter who is the issuer of NFTs in that set. People only need to be clear on what properties NFT has to satisfy in order to be treated as having utility and be interchangeable with other NFTs in the same set.\n\nTo create a fungible token you don't need an issuer. You only need a protocol that anyone can follow to issue NFTs that can become part of the fungible token set. \n\nThis reveals the power of human consensus. A community that is able to reach consensus on the set of NFTs it respects and provides utility for, creates a fertile ground for ecosystem to create a fungible token for them (by treating their respected NFTs as fungible). Effectively you have a fungible token, with an unlimited amount of independent issuers. This is another level of decentralization.\n\n## Example: content ranking for a social network platform like Hive\nLet's say you have a community of people who read articles on Hive and meet periodically (every day or every week) to reach consensus on the rankings of the posts they read. They publish their consensus publicly. This is a public good since this can help determine high-quality content on Hive. Let's call this community a \"content ranking fractal\".\n\nHow do these people decide what posts to read and rank? It's impossible for them to do this for all the posts on the platform. This question is critical if we want to make sure that rankings by this group are respected. Ideally, they should not be biased or collude with content creators when ranking posts.\n\nIt seems fair for this \"content ranking fractal\" to give attention to those content creators who deserve it. It's up to a fractal to decide who deserves it. What about Hive token-holders who help curate content on Hive by upvoting the same posts that this \"content ranking fractal\" ranks? They help implement the public good in the eyes of a fractal, so they should deserve a reward in the eyes of a fractal. And the reward this fractal can provide is attention (which can turn into being ranked by the fractal). If these upvoters do not need attention themselves they should be able to trade their right to attention to content creators that do.\n\nSo the idea goes like this. Fractal members look for NFT burn operations on some NFT platform, where NFT burned has an attribute referencing Hive transaction that upvoted the post that fractal approved. It should also be checked that the upvoter and creator of that NFT are the same party (or that the upvoter authorizes NFT creator) and that NFT for that upvote was not yet created. Additionally, the NFT burn transaction should reference another post on Hive - this is a signal that attention on this particular post is requested in exchange for the burn.\n\nSo you have upvoters on Hive, which upvote posts that fractal ranks. They create NFTs that reference transactions on Hive, which prove this. They can sell these NFTs to content creators, which utilize them to request their posts to be ranked. \n\nTo start this, all you need is one content creator finding attention from fractal valuable, and demand for these NFTs is created. Once there's at least a little bit of demand for these NFTs, there will be an incentive to be the upvoter that upvotes posts that fractal approves. Upvotes on these posts in turn mean Hive platform rewards for the creators of these posts.\n\nOf course, fractal should not rank any posts which are spam or otherwise low-quality content, even if someone burned an NFT for it. Therefore there should be no hard promises made by a fractal - they should prove themselves by setting a precedent of reacting to burns of NFTs that deserve it.\n\n---\n\nA lot of details still have to be worked out in the above example:\n1. How posts are prioritized;\n2. How much utility (attention) is each NFT worth;\n3. Structure of these kinds of fractal meetings;\n4. Etc...\n\nBut I think the idea of growing fungible tokens organically by providing utility to certain NFTs has a lot of potential and is worthy of further research. Besides the fact that it enables a fungible token, with totally decentralized issuance, it can:\n* help reward fractal members (fractal members can be posters and upvoters); \n* help distribute inflation from the platforms like Hive more fairly;\n* bring more attention to [fractal governance](https://fractally.com/blog/what-is-fractal-democracy) (by actually providing real public good to other blockchains);\n* Create incentive to participate in fractal meetings (if you don't like the results of fractal consensus - join the fractal and start influencing it);\n\n\nIn the example presented here, it would additionally help create a higher quality social network, but I think similar principles can be applied to reward voters in other blockchain governance mechanisms.\n",
      "title": "Fungibility out of non-fungible tokens",
      "author": "sim31",
      "permlink": "fungibility-out-of-non-fungible-tokens",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"format\":\"markdown\",\"description\":\"A DAO that reaches consensus on the set of NFTs it respects, incentivizes ecosystem to create a fungible token for them\",\"tags\":[\"dao\",\"blockchain\",\"consensus\",\"fractally\"],\"users\":[],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "dao"
    }
  ],
  "block": 68734223,
  "trx_id": "7bdc4987605d162a7004dd152e6640bed64aad12",
  "op_in_trx": 0,
  "timestamp": "2022-10-13T12:12:27",
  "virtual_op": false,
  "trx_in_block": 56
}

{
  "op": [
    "comment_payout_update",
    {
      "author": "sim31",
      "permlink": "rjblbm"
    }
  ],
  "block": 68728231,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 2,
  "timestamp": "2022-10-13T07:11:45",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "curation_reward",
    {
      "author": "highsteam1900",
      "reward": "9.044944 VESTS",
      "curator": "sim31",
      "permlink": "strength-in-numbers-fractally-tokenomics-solutions",
      "payout_must_be_claimed": true
    }
  ],
  "block": 68710559,
  "trx_id": "0000000000000000000000000000000000000000",
  "op_in_trx": 6,
  "timestamp": "2022-10-12T16:25:18",
  "virtual_op": true,
  "trx_in_block": 4294967295
}

{
  "op": [
    "comment",
    {
      "body": "nice",
      "title": "",
      "author": "cacxyz",
      "permlink": "re-sim31-rjm9o3",
      "json_metadata": "{\"tags\":[\"fractally\"],\"app\":\"peakd/2022.07.1\"}",
      "parent_author": "sim31",
      "parent_permlink": "edenfractal-consensus-process"
    }
  ],
  "block": 68692750,
  "trx_id": "57d3b6f7fcaa9881db0e609e4536a278a628bc8e",
  "op_in_trx": 0,
  "timestamp": "2022-10-12T01:33:42",
  "virtual_op": false,
  "trx_in_block": 35
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "cacxyz",
      "author": "sim31",
      "weight": 0,
      "rshares": 0,
      "permlink": "edenfractal-consensus-process",
      "pending_payout": "0.000 HBD",
      "total_vote_weight": 0
    }
  ],
  "block": 68692728,
  "trx_id": "384c3e5d9b608de910e0db2568b19828392dc317",
  "op_in_trx": 1,
  "timestamp": "2022-10-12T01:32:36",
  "virtual_op": true,
  "trx_in_block": 11
}

{
  "op": [
    "vote",
    {
      "voter": "cacxyz",
      "author": "sim31",
      "weight": 10000,
      "permlink": "edenfractal-consensus-process"
    }
  ],
  "block": 68692728,
  "trx_id": "384c3e5d9b608de910e0db2568b19828392dc317",
  "op_in_trx": 0,
  "timestamp": "2022-10-12T01:32:36",
  "virtual_op": false,
  "trx_in_block": 11
}

{
  "op": [
    "comment",
    {
      "body": "This is a consensus process that [EdenFractal](https://edenfractal.com/) community informally agreed to start following, since last week. Previously it was just a [google doc](https://docs.google.com/document/d/1yBhWUpWtAJap1quz9BVTPWz-CSGBM28_VzV-lzsN0bs/edit?usp=sharing) so I decided to post it here, for more immutability.\n\nWhile I was the one who wrote it down, this is really a product of more than a month of weekly discussions among fractal members. This wouldn't have been possible if not for mindful feedback on previous proposals, which in my opinion were not nearly as good as this one.\n\nA special thanks to @dansingjoy, @novacryptollc, @vladhive, @aguerrido, @thenewlegend, @machnbirdsparo, @mikelennie, @cacxyz, @lionflash @jamesmart.\n\n---\n---\n\n# Eden+Fractal consensus process proposal\n1. Make break-out room sessions longer by 15 minutes\n2. Each break-out room after determining rankings for weekly contributions tries to reach consensus on a delegate to elect (it can be different from the top contributor);\n3. Delegates from each break-out room together constitute a council for that week;\n4. Each council serves for 4 weeks (this means that at any point in time fractal has 4 councils);\n5. Councils from different weeks may have the same people in them;\n6. Council is said to \"approve a proposal\" when at least 2/3rds of its members vote to approve it, during the hour after the break-out room session;\n7. Proposal is passed once at least 3 out 4 active councils approve it, during the hour after break-out room session;\n",
      "title": "Eden+Fractal Consensus Process",
      "author": "sim31",
      "permlink": "edenfractal-consensus-process",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"description\":\"Consensus process proposal for fractally based DAOs\",\"format\":\"markdown\",\"image\":[],\"tags\":[\"fractally\",\"dao\",\"governance\",\"blockchain\",\"consensus\",\"eden\"],\"users\":[\"dansingjoy\",\"novacryptollc\",\"vladhive\",\"aguerrido\",\"thenewlegend\",\"machnbirdsparo\",\"mikelennie\",\"cacxyz\",\"lionflash\",\"jamesmart.\"]}",
      "parent_author": "",
      "parent_permlink": "fractally"
    }
  ],
  "block": 68677749,
  "trx_id": "b5937dcba53d181a16d2bb2453ddc274dcd2d18e",
  "op_in_trx": 0,
  "timestamp": "2022-10-11T13:02:18",
  "virtual_op": false,
  "trx_in_block": 64
}

{
  "op": [
    "comment",
    {
      "body": "@@ -729,16 +729,27 @@\n ionflash\n+ @jamesmart\n .%0A%0A---%0A-\n",
      "title": "Eden+Fractal Consensus Process",
      "author": "sim31",
      "permlink": "edenfractal-consensus-process",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"description\":\"Consensus process for fractally based DAOs\",\"format\":\"markdown\",\"image\":[],\"tags\":[\"fractally\",\"dao\",\"governance\",\"blockchain\",\"consensus\",\"eden\"],\"users\":[\"dansingjoy\",\"novacryptollc\",\"vladhive\",\"aguerrido\",\"thenewlegend\",\"machnbirdsparo\",\"mikelennie\",\"cacxyz\",\"lionflash\",\"jamesmart.\"]}",
      "parent_author": "",
      "parent_permlink": "fractally"
    }
  ],
  "block": 68677592,
  "trx_id": "6abb5aef39390deec836648b285798ec64ef8e15",
  "op_in_trx": 0,
  "timestamp": "2022-10-11T12:54:24",
  "virtual_op": false,
  "trx_in_block": 37
}

{
  "op": [
    "comment",
    {
      "body": "This is a consensus process that [EdenFractal](https://edenfractal.com/) community informally agreed to start following, since last week. Previously it was just a [google doc](https://docs.google.com/document/d/1yBhWUpWtAJap1quz9BVTPWz-CSGBM28_VzV-lzsN0bs/edit?usp=sharing) so I decided to post it here, for more immutability.\n\nWhile I was the one who wrote it down, this is really a product of more than a month of weekly discussions among fractal members. This wouldn't have been possible if not for mindful feedback on previous proposals, which in my opinion were not nearly as good as this one.\n\nA special thanks to @dansingjoy, @novacryptollc, @vladhive, @aguerrido, @thenewlegend, @machnbirdsparo, @mikelennie, @cacxyz, @lionflash.\n\n---\n---\n\n# Eden+Fractal consensus process proposal\n1. Make break-out room sessions longer by 15 minutes\n2. Each break-out room after determining rankings for weekly contributions tries to reach consensus on a delegate to elect (it can be different from the top contributor);\n3. Delegates from each break-out room together constitute a council for that week;\n4. Each council serves for 4 weeks (this means that at any point in time fractal has 4 councils);\n5. Councils from different weeks may have the same people in them;\n6. Council is said to \"approve a proposal\" when at least 2/3rds of its members vote to approve it, during the hour after the break-out room session;\n7. Proposal is passed once at least 3 out 4 active councils approve it, during the hour after break-out room session;\n",
      "title": "Eden+Fractal Consensus Process",
      "author": "sim31",
      "permlink": "edenfractal-consensus-process",
      "json_metadata": "{\"app\":\"peakd/2022.07.1\",\"format\":\"markdown\",\"description\":\"Consensus process for fractally based DAOs\",\"tags\":[\"fractally\",\"dao\",\"governance\",\"blockchain\",\"consensus\",\"eden\"],\"users\":[\"dansingjoy\",\"novacryptollc\",\"vladhive\",\"aguerrido\",\"thenewlegend\",\"machnbirdsparo\",\"mikelennie\",\"cacxyz\",\"lionflash.\"],\"image\":[]}",
      "parent_author": "",
      "parent_permlink": "fractally"
    }
  ],
  "block": 68677494,
  "trx_id": "3bdcafe7b846106c5651e4f13fb550b2e6a9a138",
  "op_in_trx": 0,
  "timestamp": "2022-10-11T12:49:30",
  "virtual_op": false,
  "trx_in_block": 31
}

{
  "op": [
    "effective_comment_vote",
    {
      "voter": "drew-bop",
      "author": "sim31",
      "weight": 0,
      "rshares": 0,
      "permlink": "rjblbm",
      "pending_payout": "0.000 HBD",
      "total_vote_weight": 0
    }
  ],
  "block": 68600635,
  "trx_id": "388f60df8ba7731d16d10061e0a634b8ab4dc039",
  "op_in_trx": 1,
  "timestamp": "2022-10-08T20:30:51",
  "virtual_op": true,
  "trx_in_block": 40
}

{
  "op": [
    "vote",
    {
      "voter": "drew-bop",
      "author": "sim31",
      "weight": 10000,
      "permlink": "rjblbm"
    }
  ],
  "block": 68600635,
  "trx_id": "388f60df8ba7731d16d10061e0a634b8ab4dc039",
  "op_in_trx": 0,
  "timestamp": "2022-10-08T20:30:51",
  "virtual_op": false,
  "trx_in_block": 40
}

{
  "op": [
    "custom_json",
    {
      "id": "peakd_notify",
      "json": "{\"action\":\"markAsRead\",\"date\":\"2022-10-08T15:27:28\"}",
      "required_auths": [],
      "required_posting_auths": [
        "sim31"
      ]
    }
  ],
  "block": 68594650,
  "trx_id": "3af16f0fb02dcc56f00f007d344b121c3a61b894",
  "op_in_trx": 1,
  "timestamp": "2022-10-08T15:29:33",
  "virtual_op": false,
  "trx_in_block": 55
}

{
  "op": [
    "custom_json",
    {
      "id": "notify",
      "json": "[\"setLastRead\",{\"date\":\"2022-10-08T15:27:28\"}]",
      "required_auths": [],
      "required_posting_auths": [
        "sim31"
      ]
    }
  ],
  "block": 68594650,
  "trx_id": "3af16f0fb02dcc56f00f007d344b121c3a61b894",
  "op_in_trx": 0,
  "timestamp": "2022-10-08T15:29:33",
  "virtual_op": false,
  "trx_in_block": 55
}

{
  "op": [
    "comment",
    {
      "body": "Great thoughts as usual, Tadas.",
      "title": "",
      "author": "jamesmart",
      "permlink": "re-sim31-rjfwvy",
      "json_metadata": "{\"tags\":[\"fractally\"],\"app\":\"peakd/2022.07.1\"}",
      "parent_author": "sim31",
      "parent_permlink": "fractal-blockchains"
    }
  ],
  "block": 68594305,
  "trx_id": "f78f2feba5aa9e6ea9770edcdb2cfed3f763fb96",
  "op_in_trx": 0,
  "timestamp": "2022-10-08T15:12:06",
  "virtual_op": false,
  "trx_in_block": 34
}