2022.05, 2022.06, 2022.07 - Grant Proposal - PWV

Name: PWV
Organization: pwvconsultants.com
Requested Grant:

Wallet Stable Coins WRAP Hours Rate / Hr. Period
0x12f8955F90E1Cfbc04bb49b41Ea2598E60366B8a 37200 USDC 0 240 155 USDC May 2022
0x12f8955F90E1Cfbc04bb49b41Ea2598E60366B8a 55800 USDC 0 360 155 USDC June 2022
0x12f8955F90E1Cfbc04bb49b41Ea2598E60366B8a 55800 USDC 0 360 155 USDC July 2022

For the WRAP-IOU portion, Polywrap DAO to mint the tokens at delivery (approximately July), based on actual hours worked. WRAP-IOU should go to this wallet: 0x2Dc09C1975b4D2cB30Fae34d4EfA507974827B4D.

Discussion period: Thu May 12 to Mon May 16, 2022 (3 Business Days)
Voting period: Tue May 17 to Thu May 19, 2022




PWV is a polyglot development shop with expertise in code architecture. Previously, we have contributed technical research and code architecting services to Polywrap, in the form of research documents, architecture plans, and implementation proposals and details. We have also contributed code to several major features, including recipe cookbooks and toolchain versioning.

PWV is looking to expand their engagement with Polywrap in order to undertake bigger projects within reasonable timeframes. Some of those larger projects are presented below, as well as a general backlog of issues that we are interested in working on, including documentation and contributing to the Technical Council.


Second Client Implementation

Polywrap markets itself as a cross-platform, cross-linguistic tool. We believe that implementing a second client in another language would benefit the project greatly in these early stages. We have created a proposal concerning this, which we estimate will take roughly 200–240 hours to implement effectively. At this time, we believe the imperative should be to create a Python client, and to use Wasmer as the underlying WASM runtime.

Multi-client Test Harness

With multiple clients comes the risk of implementation drift (cf. monorepo#32). To combat this, Polywrap needs a suite of tests and known I/O pairs that can be used to effectively validate feature parity between different client implementations (in addition to benchmarking, and other interesting measurable client properties). This test harness would include scaffolding code, updates to the clients (to facilitate testing), as well as a library of recipes (cf. technical-council#3) with known, expected outputs, and we estimate it will take roughly 240–300 hours to complete (against the two expected clients).

Embedded Dependencies

Given the composable nature of wrappers, it should seem common and obvious to need to include certain other wrappers as “dependencies” during wrapper development. However, when shipping those wrappers, there is currently no way to bundle them together, directly. This project would cover the inclusion of a new codegen step to insert the WASM bytecode of dependencies directly into the dependent wrapper, so that they can be packaged and run together; though, we intend to start with the “easier” project types first — applications & plugins — before getting to the “harder” one — WASM modules. We estimate that this would take roughly 160–200 hours to complete.

Depending on how quickly this goes, there may be potential to upgrade this project to cover an entire MVP of the (client-side) dependency locking feature.


Thanks for this proposal. A few questions/comments:

  1. Do you see the work proposed in the Deliverables section as happening serially or will some of that work be parallelized? From the perspective of a public roadmap, it would be great to know specifically in which quarter these new capabilities will arrive.
  2. Did we agree that Python should be the next Polywrap client? For the sake of symmetry, shouldn’t we consider Rust as the next client implementation since we will soon support Rust as a wrapper development language?
  3. Many of the backlog items listed are related to documentation that will be part of the Q2 release. I think you should take these out of the scope for this proposal since they may not be the best use of your time and may also delay your other proposed features.

Thanks for your feedback, Evan! To address your questions:

  1. We expect these proposals to be worked on in series. We want to aim for one “large project” per month, in the order that they are currently listed. While work on these projects ostensibly could be done in parallel, we are aiming to get the initial second client implementation done first so that it might be shipped with the upcoming GA release in 2022Q2. That would leave the multi-client test harness for the remainder of Q2, possibly carrying over into Q3 (especially if any technical standards/spec work is to be done before initial MVP/release); and, it would leave the dependency locking work for Q3.
  2. So the initial proposal that was made (linked above) called for the Python client to be done first. Although there is currently a good deal of work being done around Rust availability in the Polywrap ecosystem, PWV still believe that the larger Python community should be targeted initially, especially if this second client is to match cadence for the GA release of the project overall, as it would ensure more eyeballs on Polywrap and more potential users/feedback. That being said, doing the Python client first would likely push the Rust client (which is not included in this proposal) back to Q4, assuming that the multi-client test harness is a strong prerequisite for having more than two clients (and preventing drift between them).
    We’re not deadset though, and we’d be willing to swap Python for Rust for this second client implementation, we’re just concerned that implementing a Rust client would take longer (increased complexity, fewer but more in-demand devs, etc.) and that delay would likely keep it from being ready in time to ship with the rest of the project.
  3. So, given that our goal is to tackle these major projects month-to-month, the backlog necessarily will be relegated to any lulls between projects, or other downtime. Given that we intend to assign several devs to work on these, and that Jordan specifically requested one our devs (Matt) to assist with technical writing and documentation, we feel we can appropriately allocate resources to get at least some of the documentation work done in parallel with the other projects.

Hey PWV, can you add the dates to the top of this proposal?

Discussion period: Thu May 12 to Mon May 16, 2022 (3 Business Days)
Voting period: Tue May 17 to Thu May 19, 2022

Also, after the proposal passes, we’ll need to have the contract reviewed by legal and have it executed.

I’ve spoken with @namesty_dorg who’s planning to tackle the Rust client after we complete the current release we’re working towards. So as I understand it the Rust client will be developed in Q3. NOTE: the rust client has already been briefly started, so we’re not starting from 0%.