Transactional Voting

In the dreamcatcher model every transaction has a field for reference to a hash of a pull request, so for every value exchange a vote can be cast about a desired state change of anything at all, since anything that is modeled using chains can be pull requested against. How systems choose to respond to those vote signals is up to the implementors, but pure dreamcatcher projects will faithfully follow those votes directly based on some yet to be determined algorithm. This means that any time any given state change occurs, it is capable of signaling that it would like some other state change to occur.

Essential to the self correcting nature of Ambient Attribution is that anyone must be able to vote on anything at any time, with any type of weighting that they choose. This is the only way that supply chains can be corrected and made to function fairly end to end. The purest form of correction is the voting on algorithms and parameters that calculate what attribution should be, rather than direct assertions. Fairness seems to demand that all projects should be subjected to the same algorithm, too, and so it might be that the ultimate attribution algorithm is a large sampling based solution, rather than an actual formula.

Dreamcatcher projects in native mode disperse a percentage of each revenue transaction to the stack of dependencies that created the project. This percentage cannot be set by any person, as we promote algorithmic dispersals, not assertion based dispersals. Transactional Voting provides the method by which this percentage, or the algorithm that calculates this percentage is ultimately set. The algorithm can never be particular to any given project, and acts as a sort of global appraisal system, as no interested party can ever be given the power to set some parameter that could advantage them.