Any Drey Actuary can create a DAO proposal by generating the a draft document within the Drey Actuary client which is broadcast to other members, seeking comment, inscribing the final draft at a particular satoshi, and relaying the satoshi ordinal value to other Drey Actuaries over the Nostr protocol (built-in).
The voting request announcement and JSON-LD document should contain a block height of when the vote will occur. A supermajority of Drey Actuaries will be required to vote through any proposal, distribution schedule or other material decision. Distribution schedules are assigned tasks as described below.
Each JSON-LD document in the Bitcoin blockchain will contain an address to forward the satoshi to that represents a yes or no. The same will also be described in the Nostr protocol vote request. The decentralised actuarial protocol embeds capability to create a transaction at x block height to move the satoshi to a specific wallet address denoting yes or no and declared in the Nostr communication and the JSON-LD document, indicating whether an issue or schedule was agreed to or not.
This is accomplished by way of a Schnorr based threshold signature scheme, ROAST, using decentralized Nostr networks as a communication layer for a secure and encrypted method of transporting and digitally signing bitcoin transactions. This end-to-end solution solves issues with encrypted communication, coordination, optimization, and increased privacy for an enhanced threshold signature experience.
Each vote requires each Drey Actuaries to confirm their stance by engaging or ignoring the requested participation in the threshold signature scheme which results in a signed bitcoin transaction, moving the inscribed satoshi into a 'yes' wallet using funds which the Drey Actuaries control, creating a permanent records of vote confirmation.
Using ROAST, Drey Actuaries have the ability to determine among themselves which Drey Actuaries voted for or against the proposal. However, to anyone observing the bitcoin blockchain, transactions generated by using the Schnorr threshold scheme enabled by the ROAST protocol look like any Pay-to-Taproot (P2TR) spend, thus preserving vote privacy outside of the Drey Actuary circle.
Initiative / goal
The Drey Finance Voting protocol serves as a bridge between the collaborative environment enabled by Nostr and CRDTs and the immutable ledger provided by the Bitcoin blockchain. For example, Drey Actuaries might need to discuss an upgrade to a mortality table. Initially, the discussion would take place within the Drey Finance Actuary Client, utilizing Nostr's event-based communication to facilitate real-time interaction and deliberation. The proposed upgrade to the mortality table would be represented as a unique data type within the CRDT framework, allowing it to be shared, scrutinized, and modified collaboratively.
Once the Actuaries are satisfied with the proposed changes, they can use the Actuary Client to create a partially signed Bitcoin transaction. This transaction represents a formal vote on the proposal and is prepared using the Ordinal-Inscription feature of the Drey Finance platform. Ordinal-Inscription is a process in which data, such as a proposed mortality table upgrade, is embedded into a Bitcoin transaction through the use of Taproot-type transactions. This mechanism allows for important information to be stored on Bitcoin's blockchain in a secure, tamper-proof manner.
The voting process itself is facilitated by the ROAST protocol's Schnorr threshold signature algorithm. Each Drey Actuary holds a share of the signature, and a certain number of these shares - the threshold - are required to validate the transaction. Once the threshold is met, the Bitcoin transaction is finalized, effectively casting the vote. This mechanism ensures the voting process is both democratic and secure, requiring a majority consensus among the Drey Actuaries.
With the vote cast, the result is then permanently stored on the Bitcoin blockchain. This represents the final step in the seamless transition from a collaborative, mutable workspace to a secure, immutable record of consensus. The newly-updated mortality table, now validated by the Actuaries' vote, becomes an unalterable part of the blockchain.
Hypothesis
This is core capability to the Drey Actuary Client (DAC). Success would be a global acceptance that Drey Voting protocol (using Schnoor threshold) provides privacy outside of the voting participants, accountability for inside the voting circle as all other DAC instances can see if they participated in the protocol or not, and durability as the approved vote is recorded into the Bitcoin blockchain.
Acceptance criteria and must have scope
Acceptance criteria is a group of at least 10 DAC instances creating a vote proposal collectively, inscribing the proposal at a satoshi, voting on the proposal by opt in to the threshold signature creation process over opt-out of the signature process. This would be a vote yes/no user interface selection, but would direct the DAC instance whether to participate in the protocol or not.
Stakeholders
This is key capability/tech, affects all stakeholders.
Description
Any Drey Actuary can create a DAO proposal by generating the a draft document within the Drey Actuary client which is broadcast to other members, seeking comment, inscribing the final draft at a particular satoshi, and relaying the satoshi ordinal value to other Drey Actuaries over the Nostr protocol (built-in).
The voting request announcement and JSON-LD document should contain a block height of when the vote will occur. A supermajority of Drey Actuaries will be required to vote through any proposal, distribution schedule or other material decision. Distribution schedules are assigned tasks as described below.
Each JSON-LD document in the Bitcoin blockchain will contain an address to forward the satoshi to that represents a yes or no. The same will also be described in the Nostr protocol vote request. The decentralised actuarial protocol embeds capability to create a transaction at x block height to move the satoshi to a specific wallet address denoting yes or no and declared in the Nostr communication and the JSON-LD document, indicating whether an issue or schedule was agreed to or not.
This is accomplished by way of a Schnorr based threshold signature scheme, ROAST, using decentralized Nostr networks as a communication layer for a secure and encrypted method of transporting and digitally signing bitcoin transactions. This end-to-end solution solves issues with encrypted communication, coordination, optimization, and increased privacy for an enhanced threshold signature experience.
Each vote requires each Drey Actuaries to confirm their stance by engaging or ignoring the requested participation in the threshold signature scheme which results in a signed bitcoin transaction, moving the inscribed satoshi into a 'yes' wallet using funds which the Drey Actuaries control, creating a permanent records of vote confirmation. Using ROAST, Drey Actuaries have the ability to determine among themselves which Drey Actuaries voted for or against the proposal. However, to anyone observing the bitcoin blockchain, transactions generated by using the Schnorr threshold scheme enabled by the ROAST protocol look like any Pay-to-Taproot (P2TR) spend, thus preserving vote privacy outside of the Drey Actuary circle.
Initiative / goal
The Drey Finance Voting protocol serves as a bridge between the collaborative environment enabled by Nostr and CRDTs and the immutable ledger provided by the Bitcoin blockchain. For example, Drey Actuaries might need to discuss an upgrade to a mortality table. Initially, the discussion would take place within the Drey Finance Actuary Client, utilizing Nostr's event-based communication to facilitate real-time interaction and deliberation. The proposed upgrade to the mortality table would be represented as a unique data type within the CRDT framework, allowing it to be shared, scrutinized, and modified collaboratively.
Once the Actuaries are satisfied with the proposed changes, they can use the Actuary Client to create a partially signed Bitcoin transaction. This transaction represents a formal vote on the proposal and is prepared using the Ordinal-Inscription feature of the Drey Finance platform. Ordinal-Inscription is a process in which data, such as a proposed mortality table upgrade, is embedded into a Bitcoin transaction through the use of Taproot-type transactions. This mechanism allows for important information to be stored on Bitcoin's blockchain in a secure, tamper-proof manner.
The voting process itself is facilitated by the ROAST protocol's Schnorr threshold signature algorithm. Each Drey Actuary holds a share of the signature, and a certain number of these shares - the threshold - are required to validate the transaction. Once the threshold is met, the Bitcoin transaction is finalized, effectively casting the vote. This mechanism ensures the voting process is both democratic and secure, requiring a majority consensus among the Drey Actuaries. With the vote cast, the result is then permanently stored on the Bitcoin blockchain. This represents the final step in the seamless transition from a collaborative, mutable workspace to a secure, immutable record of consensus. The newly-updated mortality table, now validated by the Actuaries' vote, becomes an unalterable part of the blockchain.
Hypothesis
This is core capability to the Drey Actuary Client (DAC). Success would be a global acceptance that Drey Voting protocol (using Schnoor threshold) provides privacy outside of the voting participants, accountability for inside the voting circle as all other DAC instances can see if they participated in the protocol or not, and durability as the approved vote is recorded into the Bitcoin blockchain.
Acceptance criteria and must have scope
Acceptance criteria is a group of at least 10 DAC instances creating a vote proposal collectively, inscribing the proposal at a satoshi, voting on the proposal by opt in to the threshold signature creation process over opt-out of the signature process. This would be a vote yes/no user interface selection, but would direct the DAC instance whether to participate in the protocol or not.
Stakeholders
This is key capability/tech, affects all stakeholders.
Timeline
TBC