Ice proposed specifications

[AnuragHydro]

What is the development you want done?

Merkle tree storage for customer-business/multiparty document terms with on-chain or off-chain verification

What are the deliverables?

Internal (we intend to complete)

Ice: Smart contracts

Document Storage As a business, I want to initiate accounts with each of my customers such that: Each account can have arbitrary parameters stored in a doc (name, account creation date, payment account, pay periods, interest rates, etc, etc) defined by the business - let’s call the business the issuer to be more general Each account is associated with an account_type. The account_type is linked with:

• the issuer (address of business)
• the signatory (hydro_id of customer)
• the schema (some plain-text) schema: The understood ‘rules’ associated with each merkle structure; for example, an accountRenewalDate parameter is useless without also knowing the renewalDuration parameter, which is stored elsewhere on the merkle tree. schema can be anything from a PDF legal document to a smart contract (more on schema as a smart contract in the document enforcement section) Each parameter should be a leaf on the merkle tree Each tree should have a mandatory leaf called schema that points to the schema uploaded in conjunction with the tree (just to prove that the schema is part of what’s being signed)

Document Signatures Documents may be updated by changing a leaf (or more) and re-signing the root hash The issuer signs the root hash upon setting the terms of the document; The signatory may sign individual leaves pertinent to them, or the root hash, depending on the structure of the document Signatures consist of reconstructing the pertinent sections of the merkle tree to a given signatory and signing it For instance, if it is a multi-party document, the issuer would sign the root hash, pertaining to the entire document with a pre-defined schema, The signatory would sign the merkle structure up to the point they choose to recreate (i.e. hash_cd rather than the root hash) - signatures should get stored with the corresponding merkle trees in the smart contract

Document enforcement If schema are just a regular legal document, the implication is carried that off-chain enforcement for on-chain signatures will be conducted.

Alternatively, schema can point to a smart contract and set the requirement that for a hydro_id to sign a document within a merkle tree, the smart contract associated with the document’s schema must be a resolver for the corresponding hydro_id.

schema as a smart contract: signing an associated hash in a Merkle tree allows the payment terms to be automatically fulfilled, denominated in HYDRO as a resolver built on Snowflake through the transferVia function of Snowflake. The smart contract may re-hash components of the Merkle tree upon given intervals such as when certain terms expire and require renewed signatures.

Ice: API Should:

• Enable delegated signatures for a given merkle structure in a contract
• Create a Merkle tree for an issuer input: params as a json Input: schema Enable queries for accounts based on hydro_id, issuer_address, and account_type.

Ice: Mobile app

• Allow users to access a db of schema to view terms of documents
• Allow users to sign onto document agreements
• Signatures denominated by hydro_id

External (HCDP)

Enable storage of schema in storj, ipfs, etc Create ‘building blocks’ of specific types of smart-contract-encoded schema Create SDKs for resolver-driven contract-enforcement terms in schema

[MasterSensei]

Great work on this. Community, let's get on the external storage and SDK tasks!