Okay, I went ahead and posted a draft! Comments (and merge requests) welcome! [https://medlabboulder.gitlab.io/democraticmediums/mediums/continuous_voting/](https://medlabboulder.gitlab.io/democraticmediums/mediums/continuous_voting/)

I agree. The methods that I am working on are focused on the signal processing concepts where you have a bunch of private preference signals, which are decentralized across participants, potentially weighted by community influence (measured in token holdings ~ think signal strength a la 'how much skin in the game'), those preference are noisy time varying distributed information, and we aim to accomplish a "sensor fusion" task using a discounted integral operator, and a neuron like "trigger function" that emits a discrete event when (and if) enough action potential accumulates. So the main goal was in fact to create an array of private continuous signals into a discrete event without forcibly time boxing it. My work is generally expected to be paired with a bonding curve but is not required to be. The point of the bonding curve and integral operations together are aimed to define or redefine certain kinds of attacks prevalent in time boxed, fixed influence voting, but a lot more analysis is due. I don't have enough to publish concrete finding at this time but i am setting up for a battery of numerical experiments using cadCAD. you can check out my progress here; [https://github.com/BlockScience/conviction](https://github.com/BlockScience/conviction) apologies in advance, the documentation is shit; I haven't really prepared it for an outside audience just yet.

Here's another twitter thread on it: [https://relevant.community/crypto/post/5cee8e8f3cf05d001794671b](https://relevant.community/crypto/post/5cee8e8f3cf05d001794671b) [@mZargham](/user/profile/mZargham) could probably hop in and share some knowledge though.

I am trying to avoid forcing a token lockup. The plan is that only the proposal proposer is locking tokens; the 'voting' mechanism actually just has one select their preferences and the way those preferences effect the outcome depends on their holdings (which may be time varying) the 'conviction' operation is a discounted integrator so it will smooth over that variation without breaking the algorithms signal processing properties. The details of the implementation require 'counterfactual state' where the state isn't actually updated unless you try to act in some way. At the moment, I am just leaking bits of R&D, we've got a long way to go to a robust design and formal publications. Conviction voting implementation is deliverable [#3](/crypto/new/3) in the commons stack roadmap, ([#4](/crypto/new/4) if you count open sourcing cadCAD), so we've got way to go yet.

Here is a more recent article on Conviction Voting that explains the mechanism further, Slava. [https://medium.com/giveth/conviction-voting-a-novel-continuous-decision-making-alternative-to-governance-aa746cfb9475](https://medium.com/giveth/conviction-voting-a-novel-continuous-decision-making-alternative-to-governance-aa746cfb9475)