# DEP 0004: Client wallet WASM modules

```
status: draft
```

## Current Situation

In the current wallet implementation, we have hardcoded functionality
for the native contracts such as _Money_ and _DAO_. This makes it
difficult to support arbitrary contracts deployed on the network within
the same wallet software, as suport for any contract would have to be
written upstream (in DarkFi) and maintained by the DarkFi developers.

## Motivation: Limitations of Current Approach

The issue with this approach is that it is impossible to arbitrarily
add support for arbitrary smart contracts deployed on DarkFi to
the wallet software. Such support would have to live upstream and
would have to be maintained either by the DarkFi devs, or reviewing
submitted patches.

This slows down development and makes it difficult for contract devs
to iterate on their designs and contract functionalities.

## Proposal: Add support for plugins as WASM modules to the wallet

This proposes converting the wallet software into a standalone library
that has an integrated WASM runtime supporting modules that define
a client API for any smart contract on the DarkFi network (including
the native network contracts).

The scope of this work would also require that the current native
contract client API is rewritten in this manner as well.

The library would provide a mechanism of communication between the
WASM modules (which define contract client API) and the wallet storage
(which might be secret keys and other private information) in order
to be able to produce transactions that call certain smart contracts.

The wallet storage implementation should be arbitrary and left to
the implementors of the wallet software. The communication would
be done using wasmer's host function support - much like what is
currently being done in the DarkFi full-node and the deployed WASM
smart contracts.

The library should also implement an object ACL (Access-control list)
that WASM modules would request access to, for security reasons. This
would allow a quick overview of what a client module requires from
the wallet in order to operate correctly. For example it might be
required to produce a signature: This means that the WASM module can
export the data that needs to be signed to the wallet, the wallet can
sign this data, and export back the signature to the WASM module,
resulting in a valid signature without WASM ever gaining knowledge
of the secret key used to produce such a signature.

Implementing such functionality could also greatly simplify the way
ZK proofs are being created, as the client WASM modules can bundle
the _zkas_ circuits and define the way the proofs are to be made.
