Lycanthrope instantiates an ephemeral wallet locally which transmutes cryptocurrency blockchains.

Machine applications ("programs") may be said to be ephemeral when they start from no local state apart from the artifact necessary for their execution. An ephemeral execution builds its state by a chain of transparently displayed and inspectable local and remote execution requests. When exited ("closed", "terminated") by the user, an ephemeral wallet leaves no trace of its execution on the local machine. The only effect of its execution exists as remote calls to remote services which have changed the state of decentralised data on blockchains. As such, each ephemeral instance may be viewed as the unfolding of a distributed computation orchestrated by a local node. The unfolding of this computation is manifested in response to explicit choices indicated by the user of the ephemeral instance.

In order to be trusted, Lyncanthrope must be transparent in its execution.

The execution of Lycanthrope is broken down into a chain ("directed graph") of computations with a definite local ordering in the ephemeral instance for which all links in the chain represent decisions explicitly allowed for by user interaction ("confirmation","agency"). Each link in the chain of Lycanthrope computation has a duality between its source code and corresponding model of its effects. The source code is a composed as single artifact which can be uniquely and succinctly identified ("hashed"). The model constitutes the composition of additional artifacts related to human intelligible representation. As such each instance of the model presented to the user in Lycanthrope may or may not be complete enough for the user to choose its execution. Note that in this sense, there are many models of the execution of the source, distinguished by their utility of the given user of the model.

Within the context of Lycanthrope, each arc in the call graph may have its source code verified via code snippets displayed to its user with appropriate linkage to reputable open source repositories for further intelligibility. The model of each link describes the purpose of the execution of the source code, its inputs, the nature of the computation resource need for its execution (i.e. whether the computation it is local or remote, and for remote services some sketch of trust provenance of the service execution), and the nature of its outputs.

Modeling Lycanthrope

The Lycanthrope model identifies the specific UX elements that will effect the next link in the abstracted computation chain goals. As such the model represents the potential implications (e.g. "security with respect to transmission of a locally known secret") of following each link in an intelligible manner. Such arcs in the computation graph have default assumptions (e.g. desired key strength) reflected in input parameters which may be inspected and potentially changed by the knowledgable user. Ideally, the knowledgable user can "program" within Lycanthrope by pasting appropriate modifications to the model.

One of the main "security implications" lies in the usage of remote computation in the transversal of the Lycanthrope call graph. Remote computation may either be the download and subsequent local execution of additional code or the invocation of a remote application procedure interface (e.g. "REST").  In the case of downloading additional code to execute, the remote computation may be brought into an inspectable context before its execution (i.e. a the source code of a given snippet can be displayed for local inspection by the user before its execution).

In the case of an REST call for which the local computation has no trusted source code for execution, we ascribe statements in the model with links to provenance for claims about effects. For some instances of arc transversal -namely those which are idempotent- Lycanthrope can potentially perform multiple remote executions, testing inputs and outputs for observable fidelity to the desired computation. An example of remote idempotent executions whose observations by a security adversary has no consequence would be the retrieval of a given block in a secured chain. One may say that such a computation is a public secret, known to all potential participants in a Lycanthrope graph transversal.

In the course of the unfolding of the Lycanthrope call graph, it may be useful to the user to persist its representation via remote services. Support is provided for persisting the overall history of a given ephemeral computation, suitably stripped of sensitive information (e.g. derived ECDSA keypairs) and encrypted with a secret local to the instance. Such persistence would constitute a chain potentially useful for the user to retrieve from a future instance which shares the appropriate secrets of the instantiating instance.