2021-09 - PWV - Dependency Proposal

Name: Dependency Proposal
Organization: PWV Consultants

Requested Grant

Wallet Stable Coins WRAP Hours Rate / Hr. Period
0x6F2aC911479A921cddB68FDB0cC027Ca1e0C1Ea0 USDT `` 36 hours 165 USDT/hr Sep 2021


After the month-end, you’ll finalize your logs and then create a Snapshot proposal, referencing this page. And then here, you can reference the link to your Snapshot proposal.


Currently there is no functionality or difference between dynamic URIs, such as ENS domains, and static URIs, such as IPFS CIDs, within Polywrap. This can cause an issue if the underlying wrapper is changed for the these dynamic URIs, as it could stop an existing app from working or provide unexpected behavior. This proposal is to spec out the ability to cache the underlying static URI associated with the current dynamic URI. This will allow for these dependencies to be resolved as expected every time.

See Polywrap Dependency Locking · Issue #402 · polywrap/monorepo · GitHub for github issue.

Detailed Deliverables

Architecture Plan will be delivered along with estimates and paths for execution and development of the following features:

Dependency Locking

Known Deliverables:

  • Review and comparing existing implementations dependency locking (package-lock.json, requirements.txt, Cargo.lock, docker-compose etc.).
  • Implementation details related to how to lock these URIs down (file/folder).
  • Implementation details of how to keep these up-to-date and path for updating the locks.
  • Implementation details as to how, when, and where to generate the locks.
  • Pros and cons of specific implementation details related to security/efficiency and developer friendliness.


  • How the implementation will affect redirects.

An architecture plan will lay the roadmap for further execution and development that includes the following elements:


This section will outline Background Context, Scope, and Requirements.

Technical Plan

This section breaks down each component of the architecture of the project describing what and how and why.

System Diagram (network topology)

This lays out the physical and cloud infrastructure components and how they relate to each other.

Component Diagram

This lays out the individual components. For instance a Data Decryption component - where it lives within the system.

Component Flow

Outlines how do the components communicate with each other.


Lays out the literal steps in the processes from component to component via a real-world scenario(s).

Data Lifecycle Diagram

This outlines the state the data is in.

Data Transfer Flow Diagram

This will show the timing of how data flows around and through what protocols.


Shows inventory of all things being used, and what other alternate plans/methods were considered

Reasoning and Determination

Why we choose this path usually related to pen and paper testing or scenario breakdowns.


Third parties or vendors we source from (cloud/DC/physical).


How this will get out into the real world as a POC.

Component/Time Breakdown

Estimate of hours for each component of the technical plan.

Hard Costs Estimate Schedule

Supplemental Document (usually a spreadsheet) as needed.


How deliverable of the real world POC will be delivered.


Any outstanding questions or known unknowns. Additional information and or sections are often added depending on the project needs as they develop. Plans are typically 30-150 pages depending on what is sufficient to document what needs to be understood to build the project. The plan is typically presented as a PDF that we review in at least one meeting and then discuss in further meetings and revise for specificity. We have and can on request also modify the plan into a brief slide deck that isolates most of the diagrams, lists, and schedules.

Contributor Log


1 Like