---
tags: Meetings
---

# 3/31/2022 Update

## Agenda

1. Project Management
2. High Level Update 1: Spec Work
3. High Level Update 2: cadCAD Mechanisms Update
4. High Level Update 3: cadCAD Development Update - Testing
5. Mathematical Specification Vision/Current Changes
6. Discussion Time

## Project Management

- Mathematical specification format is being improved and iterated on by Sean
- The cadCAD model is still under development because it informs a huge amount of the mathematical specification, especially in regards to what kinds of data is needed
- Moving forward, Sean is taking on the spec with the most focus and providing support to Itamar on the cadCAD model
- Itamar will be the primary developer for the cadCAD model with Sean helping to guide + jump in where necessary

## High Level Update 1: Spec Work

- Michael gave a lot of feedback and support in terms of improving how the mathematical specification.
- We are moving to make things like the payloads of types more explicit which will make it much easier when moving to a smart contract
- All ground work is done and the spec writing should progress much more quickly with baseline cadCAD model + format decided upon

## High Level Update 2: cadCAD Mechanisms Update

- Mechanisms for withdrawal were implemented
- Behavioral mechanism that simulates delegators deciding to "wind down" their investments
- The hook for withdrawals on the pool which goes through 1. checking if a delegator is allowed to withdraw 2. modifying the withdraw amount to be equal to the minimum of that amount and the max withdraw amount 3. creating the swap numbers of currency and token
- The vault handles the withdraw after being given the swap and first takes out free funds from the broker pool and then creates a debit on the broker pool to track unpaid but still owed amounts

## High Level Update 3: cadCAD Development Update - Testing

- Primary purpose of building simple unit tests is to ensure easy hand off to the streamr team eventually
- Also aids in creating the constraints within the mathematical specification and understanding what should and should not happen

## Mathematical Specification Vision/Current

**Summary**: While there is now a fully fleshed out format to best capture the sreamr project, this specification is meant to be as helpful as possible for the streamr team so we want to ensure the way it is written lines up to how they would like it.

Spec Link: https://hackmd.io/6fN8ITTeTVyMwV3ToeApSw?view

### Current Working Formats

These formats can be modified if needed, but are likely the final formats otherwise

### Diagrams Working Format

**Legend**

Entities: Cylinder
Decisions (Behavioral): Diamond
Policy/Process: Rectangle
Mechanism: Circle
Smart Contracts: Rectangle w/ Squiggly Line
Data Sources: Pirate Ship Sail

Each block diagram will look like below with the type mappings + a legend of their type mappings

**Example: Delegator Join/Deposit/Withdrawal**


Type Legend

Red/DITM: Delegator Internal Transfer Message
Green/DID: Delegator ID

### Types Working Format

**Example: Delegator Internal Transfer Message**

These messages deal with delegators doing an internal deposit or withdraw.

| Variable | Description | Type |
| --------|------- | ----- |
| delegator_id | The ID of the delegator| Address|
| transfer_amount | The amount to be transferred| Integer|

### State (Entities) Working Format

**Example: Local State (Vault)**

**State**

| Symbol | Description | Domain |
| --------|------- | ----- |
| $\mathcal{D}_p^{d}$| Delegator d's shares in the pool p | $\mathbb{R}_{++}$ |
| $\mathcal{I}_d$| Internal balance of delegator d | $\mathbb{R}_{++}$ |
| $\mathcal{I}_b$| Internal balance of broker b | $\mathbb{R}_{++}$ |

**Stateful Metrics**
These variables can all be computed from variables within either the local or global state.

| Symbol | Description | Domain |
| --------|------- | ----- |
| $\Sigma D_d$| Total Shares for Pool | $\mathbb{R}_{++}$|

!! Brokers trigger getting the revenue? or chron job !!

### Policies Working Format

**Example: Pool Maximum Allocation**

This policy determines the maximum allocation a pool will take. It modifies the payload to be bound as the minimum of the amount and the maximum allocation.

##### Preceded By

1. Delegator Join Check

##### Followed By

1. Delegator Invest

##### Input
1. Currency Amount Message

##### Output
1. Currency Amount Message

##### Constraints
1. The currency amount must be a positive integer
2. The delegator ID must be registered in the vault
3. The pool ID must be registered in the vault
4. The delegator must have enough funds to cover the amount between internal balance and funds

### Behavioral Policy Working Format

**Example: Delegator Internal Balance Withdraw**

##### Followed By

1. Delegator Withdraw Balance

##### Output
1. Delegator Internal Balance Method

##### Constraints
1. The delegator is registered to the vault
2. The delegator has more funds in the vault than they are trying to withdraw

### Mechanism Working Format

**Example: Deposit Funds (Internal Balance)**

This mechanism takes care of delegators adding to their internal balance in the vault.

##### Preceded By

1. Delegator Internal Transfer + Join
2. Delegator Internal Transfer

##### Followed By

None

##### Input
1. Delegator Internal Transfer Message

##### Output

None

##### State Modifications

Variables:

1. currency_amount (Delegator Internal Transfer Message)
2. delegator_id (Delegator Internal Transfer Message)

State Changes:

1. funds at delegator_id -= currency_amount
2. vault internal_balance at delegator_id += currency_amount

##### Constraints
1. The currency amount must be a positive integer
2. The delegator ID must be registered in the vault
3. The delegator must have enough funds to cover the amount between internal balance and funds

### Discussion Topics

- Topic 1: Block Diagrams with Type Mappings
- Focus on emphasizing what is stateful vs. transient
- Style of block diagrams used to make it akin to looking at how API calls might work and trigger downstream functionality
- Contracts and entities have state which can be modified and dotted lines will denote a state modifying connection
- To avoid clutter, the state modifications will be detailed within the spec further down instead of diagrams
- Topic 2: Type Mappings
- Type mappings to be used for representing what data payloads should hold and will be similar to structs
- Should be a one-to-one or almost one-to-one mapping with the smart contract implementation
- Topic 3: List of Actions/Mechansisms/Types
- Behavioral Action: Actions that come from a behavior of the actors (ex: A delegator deciding to deposit funds)
- Policies: Policies that take an input, apply a policy, then return an output payload (ex: the policy for translating currency to tokens)
- Mechanisms: May take an input, and then apply some sort of mechanism to the system, generally modifying state (ex: mechanism for depositing funds into the vault)
- Types: The payload types which are being transferred between the system
- Entities: Different actors
- Smart Contracts: Special entities that denote a smart contract operating in the system
- Attributes: Attributes of entities or smart contracts which denote pieces of state
- Topic 4: Constraints
- For mechanisms, constraints should be written in terms of who can use it, who can talk to it, what states need to be for it to fire, and what payload constraints there are

## Discussion Time

- Left open