The Drey Actuary Client is a set of server side software packages that enable the federation of decentralised Drey Actuaries to contribute actuarial know-how, capital, and help secure Drey's decentralised actuarial operating system. Actuarial operations at the biggest insurance and annuity providers are hidden behind layers of bureaucracy and remain opaque to customers. This leaves the industry open to middlemen that provide little value to customers but raise costs. Blockchain and other open protocol technologies enables most actuarial operations to be both made transparent and automated via smart contracts, reducing costs and injecting transparency in fees/operations.
This document describes collaboration activities occur between Drey Actuaries, and therefore what kind of collaboration environment needs to be enabled on the Drey Actuary Client software the Drey Actuaries will run.
Initiative / goal
These are the collaboration activities Drey Actuaries will undertake with each other.
Being able to complete these activities as a set of Drey Actuaries is the goal.
Acceptance criteria and must have scope
Requirements
Browser UI includes real time document editor - each Drey Actuary Client (known forward as DAC) instance should serve a browser based document editor that handles tables, rich text, some graphics handling and is real-time (via CRDT)
Browser UI includes group and private messaging between Drey Actuaries - Nostr protocol
Posting Proposals - Browser UI can lock finalised documents for no further editing and broadcast link to list of open proposals
Scheduling Proposal Votes - Browser UI includes a block height calendar of when voting occurs. See separate Voting specification document. (TBD).
Proposal Voting - Browser UI enables for/against vote casting on individual proposals. Under the hood, the ROAST protocol over Nostr creates a transaction moving inscribed proposal document at specific satoshi into a special wallet signifying approval of proposal if the number of required Drey Actuaries (majority or super majority) vote for proposal. See separate Voting specification document. (TBD).
Create and edit bitcoin transactions - for scheduling proposal votes and distributions. See separate specification on this.
Definition of done
Testing that DAC has embedded Nostr client/server relays that enable secure comms between DAC instances - both group and private messaging
Proposals should be collaborated on by a number of DAC instances in the editor
Proposal is locked and collectively inscribed into a satoshi using Schnorr threshold sig scheme over Nostr. So editor should show raw btc tx in some instances as it relays to vote
Vote occurs and if yes satoshi is moved into special ‘approved’ wallet.
Stakeholders
All
Timeline
To achieve the goals in this epic, user journey flows should be documented, technical flows documented, signed off. Tasks/issues germinate from here.
Description
The Drey Actuary Client is a set of server side software packages that enable the federation of decentralised Drey Actuaries to contribute actuarial know-how, capital, and help secure Drey's decentralised actuarial operating system. Actuarial operations at the biggest insurance and annuity providers are hidden behind layers of bureaucracy and remain opaque to customers. This leaves the industry open to middlemen that provide little value to customers but raise costs. Blockchain and other open protocol technologies enables most actuarial operations to be both made transparent and automated via smart contracts, reducing costs and injecting transparency in fees/operations.
This document describes collaboration activities occur between Drey Actuaries, and therefore what kind of collaboration environment needs to be enabled on the Drey Actuary Client software the Drey Actuaries will run.
Initiative / goal
These are the collaboration activities Drey Actuaries will undertake with each other.
Being able to complete these activities as a set of Drey Actuaries is the goal.
Acceptance criteria and must have scope
Requirements
Definition of done
Stakeholders
All
Timeline
To achieve the goals in this epic, user journey flows should be documented, technical flows documented, signed off. Tasks/issues germinate from here.