Drey-Finance / actuary-client

Drey's decentralised actuary client and orchestrator code
Apache License 2.0
3 stars 0 forks source link

Collaboration #2

Closed spector-in-london closed 1 year ago

spector-in-london commented 1 year ago

Background

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 the what 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.

Description

These are the collaboration activities Drey Actuaries will undertake with each other.

Requirements

  1. 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)
  2. Browser UI includes group and private messaging between Drey Actuaries - Nostr protocol
  3. Posting Proposals - Browser UI can lock finalised documents for no further editing and broadcast link to list of open proposals
  4. Scheduling Proposal Votes - Browser UI includes a block height calendar of when voting occurs. See separate Voting specification document. (TBD).
  5. 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).
  6. Create and edit bitcoin transactions - for scheduling proposal votes and distributions. See separate specification on this.

Definition of done

  1. Testing that DAC has embedded Nostr client/server relays that enable secure comms between DAC instances - both group and private messaging
  2. Proposals should be collaborated on by a number of DAC instances in the editor
  3. 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
  4. Vote occurs and if yes satoshi is moved into special ‘approved’ wallet.