The Full Service API is a JSONRPC API that works with command line tools and wallet services. It provides ledger syncing and validation, account management, and funds transfer and receiving. It serves the use cases of single user (and is the backing to the MobileCoin Desktop Wallet), while also serving high performance, multi-account, multi-subaddress needs (such as backing merchant services platforms). Please see the full API documentation at: [Full Service API](https://mobilecoin.gitbook.io/full-service-api/)

[![Docs](https://img.shields.io/badge/docs-latest-blue?style=for-the-badge)](https://mobilecoin.gitbook.io/full-service-api/) 
[![Chat](https://img.shields.io/discord/844353360348971068?style=for-the-badge)](http://mobilecoin.chat/) 
[![CircleCI](https://img.shields.io/circleci/build/gh/mobilecoinofficial/full-service?token=da755dc2814021ad04ee7b31a129b41e6c7161ac&style=for-the-badge)](https://circleci.com/gh/mobilecoinofficial/full-service/tree/master) 

The API supports:
* multiple accounts
* subaddresses (unique public addresses for incoming transactions, to assign per-user)
* balance-checking (totals, and per-user-incoming)
* transaction construction & submission
* transaction history store
* hot and cold operating modes

### Show Me the Code

* [Full-Service Node](https://github.com/mobilecoinofficial/full-service): Implementation of the Full-Service Node



The Full Service API is a JSONRPC API that works with command line tools and wallet services. It provides ledger syncing and validation, account management, and funds transfer and receiving. It serves the use cases of single user (and is the backing to the MobileCoin Desktop Wallet), while also serving high performance, multi-account, multi-subaddress needs (such as backing merchant services platforms). Please see the full API documentation at: [Full Service API](https://mobilecoin.gitbook.io/full-service-api/)

Full Service API


[MobileCoin Improvement Proposals]: #mcips

Many changes, including bug fixes and documentation improvements can be
implemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be put through a
bit of a design process and produce a consensus among the MobileCoin community and
the teams.

The "MCIP" (MobileCoin Improvement Proposal) process is intended to provide a consistent
and controlled path for new features to enter the ecosystem, so that all
stakeholders can be confident about the direction the protocol is evolving in.

# [MCIP Repository]

## Table of Contents
[Table of Contents]: #table-of-contents

  - [Opening](#mcips)
  - [Table of Contents]
  - [When you need to follow this process]
  - [Team-specific guidelines]
  - [Before creating an MCIP]
  - [What the process is]
  - [The MCIP life-cycle]
  - [Reviewing MCIPs]
  - [Implementing an MCIP]
  - [MCIP Postponement]
  - [Help this is all too informal!]
  - [License]
  - [Contributions]


## When you need to follow this process
[When you need to follow this process]: #when-you-need-to-follow-this-process

You need to follow this process if you intend to make "substantial" changes to the
MobileCoin Foundation codebase, or the MCIP process itself. What constitutes a
"substantial" change is evolving based on community norms and varies depending
on what part of the ecosystem you are proposing to change, but may include the
following.

  - Any semantic or syntactic change to the APIs which are not a bugfix.
  - Removing features.
  - Changes to the interface between the clients and servers.

Some changes do not require an MCIP:

  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does
    not change meaning".
  - Additions that strictly improve objective, numerical quality criteria
    (warning removal, speedup, better platform coverage, more parallelism, trap
    more errors, etc.)
  - Additions only likely to be _noticed by_ other developers-of-mobilecoin,
    invisible to users-of-mobilecoin.

If you submit a pull request to implement a new feature without going through
the MCIP process, it may be closed with a polite request to submit an MCIP first.


### Team specific guidelines
[Team-specific guidelines]: #team-specific-guidelines

For more details on when an MCIP is required for the following areas, please see
the foundation's team-specific guidelines for:

  - [consensus](consensus.md),
  - [fog](fog.md),


## Before creating an MCIP
[Before creating an MCIP]: #before-creating-an-mcip

A hastily-proposed MCIP can hurt its chances of acceptance. Low quality
proposals, proposals for previously-rejected features, or those that don't fit
into the near-term roadmap, may be quickly rejected, which can be demotivating
for the unprepared contributor. Laying some groundwork ahead of the MCIP can
make the process smoother.

Although there is no single way to prepare for submitting an MCIP, it is
generally a good idea to pursue feedback from other project developers
beforehand, to ascertain that the MCIP may be desirable; having a consistent
impact on the project requires concerted effort toward consensus-building.

As a rule of thumb, receiving encouraging feedback from long-standing project
developers, and particularly members of the relevant team is a good
indication that the MCIP is worth pursuing.


## What the process is
[What the process is]: #what-the-process-is

In short, to get a major feature added to MobileCoin, one must first get the MCIP
merged into the MCIP repository as a markdown file. At that point the MCIP is
"active" and may be implemented with the goal of eventual inclusion into MobileCoin.

  - Fork the MCIP repo [MCIP repository]
  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is
    descriptive). Don't assign an MCIP number yet; This is going to be the PR
    number and we'll rename the file accordingly if the MCIP is accepted.
  - Fill in the MCIP. Put care into the details: MCIPs that do not present
    convincing motivation, demonstrate lack of understanding of the design's
    impact, or are disingenuous about the drawbacks or alternatives tend to
    be poorly-received.
  - Submit a pull request. As a pull request the MCIP will receive design
    feedback from the larger community, and the author should be prepared to
    revise it in response.
  - Now that your MCIP has an open pull request, use the issue number of the PR
    to update your `0000-` prefix to that number.
  - Each pull request will be labeled with the most relevant team, which
    will lead to its being triaged by that team in a future meeting and assigned
    to a member of the team.
  - Build consensus and integrate feedback. MCIPs that have broad support are
    much more likely to make progress than those that don't receive any
    comments. Feel free to reach out to the MCIP assignee in particular to get
    help identifying stakeholders and obstacles.
  - The team will discuss the MCIP pull request, as much as possible in the
    comment thread of the pull request itself. Offline discussion will be
    summarized on the pull request comment thread.
  - MCIPs rarely go through this process unchanged, especially as alternatives
    and drawbacks are shown. You can make edits, big and small, to the MCIP to
    clarify or change the design, but make changes as new commits to the pull
    request, and leave a comment on the pull request explaining your changes.
    Specifically, do not squash or rebase commits after they are visible on the
    pull request.
  - At some point, a member of the team will propose a "motion for final
    comment period" (FCP), along with a *disposition* for the MCIP (merge, close,
    or postpone).
    - This step is taken when enough of the tradeoffs have been discussed that
    the team is in a position to make a decision. That does not require
    consensus amongst all participants in the MCIP thread (which is usually
    impossible). However, the argument supporting the disposition on the MCIP
    needs to have already been clearly articulated, and there should not be a
    strong consensus *against* that position outside of the team. Team
    members use their best judgment in taking this step, and the FCP itself
    ensures there is ample time and notification for stakeholders to push back
    if it is made prematurely.
    - For MCIPs with lengthy discussion, the motion to FCP is usually preceded by
      a *summary comment* trying to lay out the current state of the discussion
      and major tradeoffs/points of disagreement.
    - Before actually entering FCP, *all* members of the team must sign off;
    this is often the point at which many team members first review the MCIP
    in full depth.
  - The FCP lasts 1 business days.
  - In most cases, the FCP period is quiet, and the MCIP is either merged or
    closed. However, sometimes substantial new arguments or ideas are raised,
    the FCP is canceled, and the MCIP goes back into development mode.

## The MCIP life-cycle
[The MCIP life-cycle]: #the-mcip-life-cycle

Once an MCIP becomes "active" then authors may implement it and submit the
feature as a pull request to the relevant repo. Being "active" is not a rubber
stamp, and in particular still does not mean the feature will ultimately be
merged; it does mean that in principle all the major stakeholders have agreed
to the feature and are amenable to merging it.

Furthermore, the fact that a given MCIP has been accepted and is "active"
implies nothing about what priority is assigned to its implementation, nor does
it imply anything about whether a developer has been assigned the task of
implementing the feature. While it is not *necessary* that the author of the
MCIP also write the implementation, it is by far the most effective way to see
an MCIP through to completion: authors should not expect that other project
developers will take on responsibility for implementing their accepted feature.

Modifications to "active" MCIPs can be done in follow-up pull requests. We
strive to write each MCIP in a manner that it will reflect the final design of
the feature; but the nature of the process means that we cannot expect every
merged MCIP to actually reflect what the end result will be at the time of the
next major release.

In general, once accepted, MCIPs should not be substantially changed. Only very
minor changes should be submitted as amendments. More substantial changes
should be new MCIPs, with a note added to the original MCIP. Exactly what counts
as a "very minor change" is up to the team to decide; check
[Team-specific guidelines] for more details.


## Reviewing MCIPs
[Reviewing MCIPs]: #reviewing-mcips

While the MCIP pull request is up, the team may schedule meetings with the
author and/or relevant stakeholders to discuss the issues in greater detail,
and in some cases the topic may be discussed at a team meeting. In either
case a summary from the meeting will be posted back to the MCIP pull request.

A team makes final decisions about MCIPs after the benefits and drawbacks
are well understood. These decisions can be made at any time, but the team
will regularly issue decisions. When a decision is made, the MCIP pull request
will either be merged or closed. In either case, if the reasoning is not clear
from the discussion in thread, the team will add a comment describing the
rationale for the decision.


## Implementing an MCIP
[Implementing an MCIP]: #implementing-an-mcip

Some accepted MCIPs represent vital features that need to be implemented right
away. Other accepted MCIPs can represent features that can wait until some
arbitrary developer feels like doing the work. Every accepted MCIP has an
associated epic tracking its implementation in a repository; thus that
associated epic can be assigned a priority via the triage process that the
team uses for all issues in a repository.

The author of an MCIP is not obligated to implement it. Of course, the MCIP
author (like any other developer) is welcome to post an implementation for
review after the MCIP has been accepted.

If you are interested in working on the implementation for an "active" MCIP, but
cannot determine if someone else is already working on it, feel free to ask
(e.g. by leaving a comment on the associated issue).


## MCIP Postponement
[MCIP Postponement]: #mcip-postponement

Some MCIP pull requests are tagged with the "postponed" label when they are
closed (as part of the rejection process). An MCIP closed with "postponed" is
marked as such because we want neither to think about evaluating the proposal
nor about implementing the described feature until some time in the future, and
we believe that we can afford to wait until then to do so. Historically,
"postponed" was used to postpone features until after 1.0. Postponed pull
requests may be re-opened when the time is right. We don't have any formal
process for that, you should ask members of the relevant team.

Usually an MCIP pull request marked as "postponed" has already passed an
informal first round of evaluation, namely the round of "do we think we would
ever possibly consider making this change, as outlined in the MCIP pull request,
or some semi-obvious variation of it." (When the answer to the latter question
is "no", then the appropriate response is to close the MCIP, not postpone it.)


### Help this is all too informal!
[Help this is all too informal!]: #help-this-is-all-too-informal

The process is intended to be as lightweight as reasonable for the present
circumstances. As usual, we are trying to let the process be driven by
consensus and community norms, not impose more structure than necessary.


## License
[License]: #license

This repository is licensed as:

* MIT license ([LICENSE](LICENSE) or https://opensource.org/licenses/MIT)

### Contributions
[Contributions]: #contributions

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be licensed as above, without any additional terms or conditions.


[MCIP repository]: https://github.com/mobilecoinfoundation/mcips


[MobileCoin Improvement Proposals]: mcips

Proposals

We will reward the community members and developers who report bugs and security vulnerabilities.

1. Please report security vulnerabilities by email to info@mobilecoin.com
1. Please report network issues to the main GitHub for mobilecoin: https://github.com/mobilecoinfoundation/mobilecoin/issues. 
2. Please report documentation issues to the GitHub for the developer-portal: https://github.com/mobilecoinofficial/developer-portal
3. Search both open and closed tickets to make sure your bug report is not a duplicate.
4. To participate in community discussions, please use the community discord server at [https://mobilecoin.chat](https://mobilecoin.chat).


We will reward the community members and developers who report bugs and security vulnerabilities.

Bug Bounties

MobileCoin is an open source project and has several contributors. The Roadmap is now live and public for all to view. You can view what is Planned, In Progress, and Complete on the main page, and you can submit feature requests through the feedback tool. 
http://mobilecoin.canny.io


Roadmap

Open-source technology is publicly auditable. To build trusted systems, we must start with making our code public. In doing so, we support the community in verifying that the intention of our design matches our implementation. We can build secure software in a world where anyone can audit our technology, which is why we are committed to keeping our payments protocol open-source, now and forever.

There are two GitHubs for Mobilecoin:
- [MobileCoin Foundation GitHub](https://github.com/mobilecoinfoundation/) - this GitHub contains all the code relevant to the blockchain, consensus, and fog projects. It is managed by the Foundation and follows the improvement proposal process.
- [MobileCoin Official GitHub](https://github.com/mobilecoinofficial/) - this GitHub contains all the wallets, bots, and integrations. It is managed by the core-dev team and 

All of our audits are made publicly accessible after careful review:
- [MobileCoin Audit](https://github.com/trailofbits/publications/blob/master/reviews/Mobilecoin.pdf)
- [BFT Audit](https://github.com/trailofbits/publications/blob/master/reviews/MobileCoinBFT.pdf)
- [Fog Audit](https://github.com/trailofbits/publications/blob/master/reviews/MobilecoinFog.pdf)


Open-source technology is publicly auditable. To build trusted systems, we must start with making our code public. In doing so, we support the community in verifying that the intention of our design matches our implementation. We can build secure software in a world where anyone can audit our technology, which is why we are committed to keeping our payments protocol open-source, now and forever.

Audits

We are now accepting [grant applications](https://v2ius4kukp9.typeform.com/to/G8aVW4z7). The new application is the first step in the newly MobileCoin Developer Grant Program, a community-focused source of funding and support for promising developers and teams. 

"The purpose of the program is to grow the developer community, encourage collaboration amongst developers, and foster open-source projects to promote further adoption," Colin Lowenberg, the Head of Developer Relations for MobileCoin. 

Inspired by startup programs like AWS Activate and Y Combinator, the MobileCoin Developer Program offers several benefits for developers including:

-   Funding -- Developers will receive funds in MobileCoin (MOB) or US Dollars (USD) based on their team size and project milestones.
-   Office Hours: Grant development teams will meet with MobileCoin each month and receive guidance and best practices.
-   Tools & Resources -- Early access to the latest open source documentation and resources 
-   Technical Support -- Direct and responsive support from MobileCoin team members in a special Discord channel
-   Networking -- Introductions to industry leaders, investors, and other development teams.
-   Demo Days: top developers will present their projects to investors, advisors, and developers in the MobileCoin community via blogs and live streams.

Grants will be awarded to developers who submit proposals and follow through on their commitments. Funding for grant recipients will be distributed based on key milestones. demonstrated with open-source software and demos, and shown a willingness to remain open-source and collaborate with the MobileCoin community.

Milestones for each project will be determined as part of the grant application. A milestone is a goal, such as the development of a feature, the release of a working beta, or the completion of the work. Developers who complete their milestones will present their work to the community on Demo Day.

What types of projects will be funded?
--------------------------------------

We are open to any ideas that add value to the MobileCoin ecosystem. We are committed to a transparent process and would like to set expectations for the types of projects that will be considered for funding. Developers who apply for grants from the developer program will need to outline how their contributions will add value to the MobileCoin ecosystem. [MobileCoin Ecosystem](http://developers.mobilecoin.com/)

Infrastructure Projects

We are looking for developers who can build the tools and infrastructure needed to run the MobileCoin network. Examples Include: Wallets, Block Explorers, APIs, Frameworks, and Component Libraries.

Payments 

The better the user experience of MobileCoin, the stronger the value. MobileCoin is seeking projects that support the development of integration with a wide range of payments use cases including: Peer-to-peer, Invoicing, Payroll, Point of Sale, Remittances

Sustainability 

MobileCoin is committed to remaining carbon-negative and planet-friendly. We seek to attract projects that address environmental impact. These sorts of projects align strongly with our values, as they  ensure we are responsibly building a better blockchain environment.

[Start your Grant Application](https://v2ius4kukp9.typeform.com/to/G8aVW4z7)


We are now accepting [grant applications](https://v2ius4kukp9.typeform.com/to/G8aVW4z7). The new application is the first step in the newly MobileCoin Developer Grant Program, a community-focused source of funding and support for promising developers and teams.

Grants

MobileCoin launched new bounties for the open source developer community on [Gitcoin](https://gitcoin.co/mobilecoinofficial/bounties) making it easy for over 312,000 active developers to work with MobileCoin -- and grow the [ecosystem](https://developers.mobilecoin.com/ecosystem) of apps and integrations for MobileCoin. Gitcoin is a community of builders, creators, and protocols at the center of open web ecosystems. Gitcoin's community is creating infrastructure for Web 3 --- a diverse range of tools, technologies, and networks that enable people to work for the open internet. MobileCoin is using Gitcoin to fund projects, build community, and teaming up with the Gitcoin community to create the future of digital payments. 

### What kind of projects will be built with Gitcoin?

MobileCoin is offering bounties for developers who find bugs and security issues, as well as create new features and integrations. Several new bounties will be announced over the next few weeks and months. Some of the use cases that will be published on Gitcoin include:

-   Security Vulnerabilities: We're looking to increase resistance to attack by tapping into the ethical hacker community. Bounties for security hackers will help MobileCoin understand new attack surfaces, hunt bugs, test apps, and identify vulnerabilities.
-   Signal Bots: MobileCoin's Forest SDK for Signal Bots has been used in several apps including[ Imogen](https://developers.mobilecoin.com/ecosystem/imogen), a generative AI bot that creates art, and[ Hotline](https://developers.mobilecoin.com/ecosystem/hotline), a subscription and notification bot used for air drops. We are seeking developers to build more bots, such as a "Shopping Bot" that can list products and facilitate sales using MobileCoin directly within the Signal app. 
-   Windows Wallet: Our community wants a Windows version of the MobileCoin wallet. MobileCoin's core team resources have been focused on secure mobile apps for iPhones and Androids, leaving us without the bandwidth to develop it ourselves.. By funding this bounty, we aim to enable a whole new class of power users and developers. 
-   Browser Extension: The[ Fennec](https://developers.mobilecoin.com/ecosystem/fennec) wallet provides MobileCoin holders with an easy-to-use wallet directly in their browser. However, the extension is not built specifically for MobileCoin and a faster, simpler solution is desired to support sending, receiving, and paying with MOB on websites.
-   Blockchain Analytics: While the MobileCoin blockchain is opaque and does not let users snoop on wallets and their transactions, there is an interest from the community to see more details on the circulating supply, the number of nodes, the seconds per transaction, and overall number of new blocks on the blockchain. Funding this issue will likely require working closely with the core team on requirements.
-   Online Shopping Plugins: In addition to the WooCommerce plugin, we want to offer the community funding to begin integration with more online stores.
-   Developer Tools & Frameworks: We saved the best for last! MobileCoin SDKs allow developers to easily integrate MobileCoin into mobile apps, but there are many more platforms for developers and users. Building tools that integrate easily with frameworks like React and Flutter will allow developers to jumpstart their integration with MobileCoin.

Blockchain Explorer
-------------------

At a high level, the goal is to create a new block explorer which connects to the [Full Service API](https://developers.mobilecoin.com/guides/full-service-api/). The block explorer should allow a user to safely enter their private keys to query the block explorer for relevant data about their own transactions.

Currently, the[ MobileCoin Foundation's Block Explorer](https://developers.mobilecoin.com/ecosystem/block-explorer) is an open source block explorer providing detailed blockchain data across the MobileCoin Mainnet. This block explorer also supports Tor, and is tracking-free. Right now, the block explorer runs off of the[ MobileCoinD](https://developers.mobilecoin.com/guides/deprecated/mobilecoind/) API, but we are deprecating this project and refreshing it to run on the Full Service API.

You can apply to build the new [blockchain explorer on Gitcoin](https://gitcoin.co/issue/mobilecoinofficial/developer-grants/1/100028771). 

WooCommerce Plugin
------------------

The goal of the plugins project is to enable a payments option for MobileCoin during checkout on the online shopping platform, WooCommerce. The end-users of this plugin should be able to add the plugin to their eCommerce store to accept and process payments using the MobileCoin (MOB) cryptocurrency. MobileCoin's blockchain can process payments in under 5 seconds with negligible transaction fees (0.0004 MOB).

MobileCoin's core engineering team has already done much of the development and released an example plugin for the popular[ WooCommerce store for WordPress](https://developers.mobilecoin.com/ecosystem/woocommerce) to accept MOB as a payment method. You can find the open source code for the plugin on[ GitHub](https://github.com/mobilecoinofficial/mobilecoin-payments-plugin).

This plugin is still in the development phase, and we are seeking developers to take over this project and update the plugin so that it can be used successfully by online stores on WordPress.

You can apply to build the [WooCommerce integration on Gitcoin](https://gitcoin.co/issue/mobilecoinofficial/developer-grants/3/100028880).


MobileCoin launched new bounties for the open source developer community on [Gitcoin](https://gitcoin.co/mobilecoinofficial/bounties) making it easy for over 312,000 active developers to work with MobileCoin -- and grow the [ecosystem](https://developers.mobilecoin.com/ecosystem) of apps and integrations for MobileCoin. Gitcoin is a community of builders, creators, and protocols at the center of open web ecosystems. Gitcoin's community is creating infrastructure for Web 3 --- a diverse range of tools, technologies, and networks that enable people to work for the open internet. MobileCoin is using Gitcoin to fund projects, build community, and teaming up with the Gitcoin community to create the future of digital payments.

Bounties

Contributing


The Electron Wallet is a user-friendly desktop wallet with support for transaction history, encrypted contact book, gift codes,  payments, cold-wallet capabilities. The MobileCoin desktop wallet is available for [Mac](https://get.mobilecoin.com/mac), [Ubuntu](https://get.mobilecoin.com/ubuntu), [Redhat](https://get.mobilecoin.com/redhat) and [Linux](https://get.mobilecoin.com/linux) operating systems. Check out all of the [releases on our GitHub](https://github.com/mobilecoinofficial/desktop-wallet/releases).

### Show Me the Code

* [Desktop Wallet](https://github.com/mobilecoinofficial/desktop-wallet): MobileCoin Desktop Wallet implementation

![](https://mobilecoinwp.wpengine.com/wp-content/uploads/2021/10/MobileCoin_Wallet_DesktopDownloadProcess_07-1-e1635381496489.png)

## Guide For Mac OS Users

If you've already downloaded and set up your MobileCoin desktop wallet, [learn how to add funds here. ](https://mobilecoin.com/news/how-to-buy-mob-in-the-us)

1.  1\. Allow downloads from [mobilecoin.com](http://mobilecoin.com/).
2.  2\. Open the MobileCoin Wallet installer from your downloads folder.
3.  3\. Drag the Wallet icon into your Applications folder.
4.  4\. Double-click the MobileCoin Wallet app in your Applications folder.
5.  5\. Allow your Mac to open the app.

    ![](https://mobilecoinwp.wpengine.com/wp-content/uploads/2021/10/MobileCoin_Wallet_DesktopDownloadProcess_07-1-859x1024.png)
6.  6\. Create a password for your Wallet and click the TERMS OF USE.
7.  7\. Read through TERMS OF USE carefully.
8.  8\. Once complete, click CLOSE TERMS OF USE to return to set up.
9.  9\. Check the box next to "I have read and accept the TERMS OF USE" and click CREATE WALLET.
10. 10\. Choose an Account Name if desired and click CREATE ACCOUNT.

    ![](https://mobilecoinwp.wpengine.com/wp-content/uploads/2021/10/MobileCoin_Wallet_DesktopDownloadProcess_11-849x1024.png)
11. 11\. Click SHOW SECRET ENTROPY. Save your Secret Entropy in a secure location and click I HAVE SECURED MY ENTROPY.
12. 12\. Confirm that you have secured your entropy, or go back to view it again.![](https://mobilecoinwp.wpengine.com/wp-content/uploads/2021/10/MobileCoin_Wallet_DesktopDownloadProcess_13-853x1024.png) 
13. 13\. Set a Transaction Pin and a minimum MobileCoin amount for pin-activated transfers.
14. 14\. Click SET PIN.\
    ![](https://mobilecoinwp.wpengine.com/wp-content/uploads/2021/10/MobileCoin_Wallet_DesktopDownloadProcess_14-853x1024.png)

Welcome to MobileCoin Wallet! [Now you're ready to add some money to your wallet!](https://mobilecoin.com/news/how-to-buy-mob-in-the-us)


The Electron Wallet is a user-friendly desktop wallet with support for transaction history, encrypted contact book, gift codes,  payments, cold-wallet capabilities. The MobileCoin desktop wallet is available for [Mac](https://get.mobilecoin.com/mac), [Ubuntu](https://get.mobilecoin.com/ubuntu), [Redhat](https://get.mobilecoin.com/redhat) and [Linux](https://get.mobilecoin.com/linux) operating systems. Check out all of the [releases on our GitHub](https://github.com/mobilecoinofficial/desktop-wallet/releases).

Electron Wallet

# MobileCoin command-line interface
Command line interface and client library for MobileCoin full-service node.


## Installation

```shell
sudo apt install python3-pip
pip3 install .
```

Check that it is installed.
```shell
mobcli -h
```

## Set up environment variables.

Copy the config file to your home directory.
```shell
cp mc_env.sh ~/.mc_env.sh
```

Add the following lines to your .bashrc:
```shell
if [ -f "$HOME/.mc_env.sh" ]; then
    source "$HOME/.mc_env.sh"
fi
```

The environment variables file specifies to connect to the test network by default, but
you can change it to connect to the main network if you know what you're doing, and are
confident you will not lose actual funds.


## Start the server

```shell
mobcli start
```


## List of commands

- start
- stop
- create
- rename
- import
- export
- delete
- list
- send


MobileCoin command-line interface
Command line interface and client library for MobileCoin full-service node.

Python CLI

The Forest SDK is a framework for running payments-enabled chat and utility bots for [Signal Messenger](https://signal.org/en/).

To get familiarised with deploying and running a forest bot, we've provided a short tutorial to teach you how to deploy hellobot, the simplest possible forest bot.

## High Level Overview ##

In this tutorial you will:

 * Install Pre-Requisites.
 * Install signal-cli and register a Signal account for your bot.
 * Deploy the bot!

Please see [this document](https://github.com/mobilecoinofficial/forest/blob/main/README.md) for details.


The Forest SDK is a framework for running payments-enabled chat and utility bots for [Signal Messenger](https://signal.org/en/).

Signal Chat Bots

Imogen is a Signal Bot that generates images using VQGan and CLIP. These images are often affectionately referred to as Imoges. To have Imogen generate an Imoge for you you can join Imogen's Signal Group Chat.

### Imogen on Signal
Message the [Imogen Chat Bot](https://signal.me/#p/+14159495511) on Signal.  Just say the word "imagine" followed by your imagination. The phone number is +1-415-949-5511.

### Imogen on Twitter ###

Imogen posts all the images from groups on [her Twitter account](https://twitter.com/dreambs3). You can browse there to get an idea of what other users are collaborating with Imogen. Since posts in the group get posted to twitter automatically, please be mindful of your prompts to Imogen. Ask an administrator if you want an Imoge taken down from Twitter. 

# How To Use #

In a Group or a direct message send a message of the form:

`   
/imagine [prompt]
`

Where [prompt] is a description of the image you want to generate. Imogen will generate an imoge for you based on the prompt:

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/imagine.png">

`/imagine` uses the [ImageNet dataset](https://www.image-net.org/) as the training data for its images. This is a general dataset trained on many images on the Internet. Using the `/paint` command instead will generate an image using the [WikiArt dataset](https://github.com/cs-chan/ArtGAN/blob/master/WikiArt%20Dataset/README.md), which produces more painting-like images:

`
/paint [prompt]
`


<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/paint.png">

 


There are some special commands to specify style for the image.
- /dark_fantasy
- /pastel,
- /psychic,
- /synthwave,
- /ukiyo,
- /vibrant

These are equivalent to appending the style after the imagine prompt. `/dark_fantasy Kirby` -> `/imagine dark fantasy Kirby`

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/darkfantasy.png">

Imogen can draw in many more styles than those, try asking for a style you like, or ask her to channel a particular artist's style.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/paint2.png">


## Priority Queue ##

Imogen features a priority queue that will guarantee your image is generated sooner in times of high activity. To make use of Imogen's paid features send her a payment with Signal Pay. To do this first make sure you have [Payments enabled on Signal](https://support.signal.org/hc/en-us/articles/360057625692-In-app-Payments). Then send Imogen a direct message and attach a payment using the + button.

You can message Imogen by visiting  [this link](https://signal.me/#p/+14159495511 ) which will open on Signal Messenger.  


<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/payment.jpg">  <img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/payment3.jpg"> 

You will receive a direct message informing you of the receipt of your payment and your new balance.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/payment-received.jpg">

You can check your current balance with `/balance`.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/balance.jpg">

When you have Imogen balance your requests are automatically added to the priority queue. The current cost per image is USD $0.10. 

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/priority2.png">

Imogen will inform you via direct message when your balance reaches 0. At that point you may continue using the free Imogen queue, or send another payment to top up your balance.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/balance2.png">



<br>

### Additional Perks of the Priority Queue ###

There's a per person limit of how many prompts you can have Imogen generate at once. Priority requests bypass that limit. There might also be additional paid features in the future. If you have a good idea for a paid feature, please submit it as a feature request. 

Imogen wishes to remain free for anyone to collaborate with her. By making use of the paid queue and tips you can ensure that Imogen continues to collaborate on art with users from all over the world.

 
<br>

## Tipping ##

You can donate tips to Imogen to show your support. If you have Imogen balance, you can tip some of that balance by using `/tip [amount]`, amounts are currently in USD.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/tip1.jpg">

Using `/tip all` will donate your whole balance as a tip.


<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/tipall.jpg">

Finally, you can send a payment as a tip directly by writing "Tip" in the notes field for the payment. Your payment will automatically be added as a tip to Imogen.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/tip2.jpg">

<br>

## Full list of available commands ##

`/balance`  
returns your Imogen balance for priority requests

`/help`  
Display the help text

`/help [commmand]`  
Explains a specific Command

`/imagine [prompt] `  
Generates an image based on [prompt]. 

`/nopost [prompt]`  
Functions like the `/imagine` command but the generated Image does not post to Twitter.

`/paint [prompt]`  
Generate an image using the WikiArt database and your prompt, generates painting-like images.

`/tip [ammount]`  
Subtracts [ammount] from your Imogen Balance and donates it as a tip. Ammounts are in USD.

`/tip all`  
Subtracts all your available balance and donates it as a tip.

`/signalpay`  
Displays the Signal Pay help text which will help you get set up sending and receiving payments over Signal. You can use Signal Pay to make use of Imogen's paid features.

`/status `  
Displays Imogen's status

## Advaced Techniques ##


### Starting Image: ###

Imogen can generate your image based on a starting image. Attach an image and use one of the generative commands (`/imagine`, `/paint`) and Imogen will generate an image based on your prompt and the starting image.

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/starting1.png">  <img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/starting2.png">

### Videos: ###
You can give imogen multiple prompts separated by "//" and Imogen will generate a video that transitions between the prompts. Will take longer than a regular `/imagine`.
Example:  
`/imagine Jane // Cake `

<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/video.png">  <img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/video2.gif">

### Transform: ###
You can combine the starting image and the video functionality to make images that dissolve into imoges. 
Attach an image and use one of the generative commands, start your prompt with `//` and your target. Example:  

`/imagine // cake`


<img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/video3.png">  <img width=250px src="https://raw.githubusercontent.com/mobilecoinofficial/forest/main/imogen/examples/video4.gif">

# Under the Hood #

Imogen is composed of two separate systems. There's the machine learning program that trains the models to generate the images. And then there's the queue management system and Signal interface. The code in this repository constitutes the latter.

## Contributing to Imogen ## 

We welcome pull requests, and issues, but most importantly you can contribute to Imogen by collaborating with her. Join the Signal Groups, make art with her, use her paid features and donate tips. 

There's often discussions about the science and machine learning models behind Imogen on these groups, and you can help by participating in those discussions.


<a class="twitter-timeline" data-lang="en" data-theme="dark" href="https://twitter.com/dreambs3?ref_src=twsrc%5Etfw">Tweets by dreambs3</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


Imogen is a Signal Bot that generates images using VQGan and CLIP. These images are often affectionately referred to as Imoges. To have Imogen generate an Imoge for you you can join Imogen's Signal Group Chat.

Imogen: Imoge Generator

Signal SDK


The MobileCoin iOS Swift SDK is a library to access the MobileCoin blockchain from Apple iPhones. Please see the [MobileCoin iOS Swift SDK Documentation](https://mobilecoin.gitbook.io/mobilecoin-swift/). 

[![Docs](https://img.shields.io/badge/docs-latest-blue?style=for-the-badge)](https://mobilecoin.gitbook.io/mobilecoin-swift/) 
[![Chat](https://img.shields.io/discord/844353360348971068?style=for-the-badge)](http://mobilecoin.chat/) 
[![CircleCI](https://img.shields.io/circleci/build/gh/mobilecoinofficial/MobileCoin-Swift?token=da755dc2814021ad04ee7b31a129b41e6c7161ac&style=for-the-badge)](https://circleci.com/gh/mobilecoinofficial/MobileCoin-Swift/tree/master) 

## Show me the code
|Directory |Description |
| :-- | :-- |
| [Docs](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/docs) | Integration Guide. |
| [Example](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/Example) | Example application. |
| [ExampleHTTP](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/ExampleHTTP) | Example "HTTP Only" application. |
| [Sources](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/Sources) | Sources for the MobileCoin Swift SDK. |
| [Tests](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/Tests) | Tests. |
| [Vendor](https://github.com/mobilecoinofficial/MobileCoin-Swift/tree/master/Vendor) | iOS Artifacts. |

## Support

For troubleshooting help and other questions, please join our [discord server](https://mobilecoin.chat/).

You can also open a technical support ticket via [email](mailto://support@mobilecoin.com).




The MobileCoin iOS Swift SDK is a library to access the MobileCoin blockchain from Apple iPhones. Please see the [MobileCoin iOS Swift SDK Documentation](https://mobilecoin.gitbook.io/mobilecoin-swift/).

iOS Swift SDK

The MobileCoin Android SDK is a library to access the MobileCoin blockchain from Android phones. Please see the [MobileCoin Android SDK Documentation](https://mobilecoin.gitbook.io/mobilecoin-android/). 

[![Documentation](https://img.shields.io/badge/docs-latest-blue?style=for-the-badge)](https://mobilecoinofficial.github.io/android-sdk/)
[![Chat](https://img.shields.io/discord/844353360348971068?style=for-the-badge)](http://mobilecoin.chat/) 
[![CircleCI](https://img.shields.io/circleci/build/gh/mobilecoinofficial/android-sdk?token=eaa920ba2ba6916857aec7ef3c1a9d217a128717&style=for-the-badge)](https://circleci.com/gh/mobilecoinofficial/android-sdk/tree/master) 

## Show me the code
|Directory |Description |
| :-- | :-- |
| [docs](https://github.com/mobilecoinofficial/android-sdk/tree/master/docs) | Integration Guide for the Android SDK. |
| [main](https://github.com/mobilecoinofficial/android-sdk/tree/master/android-sdk/src/main/java/com/mobilecoin) | Sources for the MobileCoin Android SDK. |
| [androidTest](https://github.com/mobilecoinofficial/android-sdk/tree/master/android-sdk/src/androidTest/java/com/mobilecoin/lib) | Tests. |
| [testApp](https://github.com/mobilecoinofficial/android-sdk/tree/master/testApp) | Test application using the Android SDK. |

## Support
For troubleshooting help and other questions, please join our [discord server](https://mobilecoin.chat/).

You can also open a technical support ticket via [email](mailto://support@mobilecoin.com).


The MobileCoin Android SDK is a library to access the MobileCoin blockchain from Android phones. Please see the [MobileCoin Android SDK Documentation](https://mobilecoin.gitbook.io/mobilecoin-android/).

Android SDK

Wordpress powers 40% of the world's websites. WooCommerce powers over 28% of all online stores. MobileCoin Payments Plugin enables WooCommerce stores to accept MOB as a Payment Method. Come join our private alpha. 

When you use WooCommerce as your website's e-commerce engine, our plugin (MobileCoin Payments) will enable you to add a new MOB Payment Method to use within WooCommerce.

#### Show Me the Code
[WooCommerce Plugin](https://github.com/mobilecoinofficial/mobilecoin-payments-plugin)


Wordpress powers 40% of the world's websites. WooCommerce powers over 28% of all online stores. MobileCoin Payments Plugin enables WooCommerce stores to accept MOB as a Payment Method. Come join our private alpha.

Wordpress Plugin


#### MobileCoin Python Package

The [`mobilecoin` Python Package](https://pypi.org/project/mobilecoin/) provides python bindings to the `mobilecoind` API.

It can be installed with:

```sh
pip3 install mobilecoin
```

The prerequisite to using these bindings is to run `mobilecoind`, the ledger syncing and wallet daemon. Please see the
[mobilecoind documentation](https://github.com/mobilecoinfoundation/mobilecoin/tree/master/mobilecoind) for instructions
to build and run `mobilecoind`.

#### Jupyter Notebook

Please explore our [Jupyter Notebook Example Wallet](https://github.com/mobilecoinfoundation/mobilecoin/blob/master/mobilecoind/clients/python/jupyter/wallet.ipynb), 
using the `mobilecoin` Python package to send and receive payments.

#### Show Me the Code
* [MobileCoin Python Package](https://github.com/mobilecoinfoundation/mobilecoin/tree/master/mobilecoind/clients/python/lib)
* [MobileCoin Jupyter Notebook Example Wallet](https://github.com/mobilecoinfoundation/mobilecoin/tree/master/mobilecoind/clients/python/jupyter)


Python SDK


# Java sample client and CLI tool

This code serves both as an example of how to use the services provided by mobilecoind
in Java through gRPC and as a CLI tool to interact with mobilecoind.

To use it, you must have an instance of mobilecoind running, this is typically run
locally. You can find instructions at https://github.com/mobilecoinfoundation/mobilecoin/tree/master/mobilecoind

A gradle wrapper is included, `gradlew` (or `gradlew.bat` on Windows). The most simple call, assuming you are running
mobilecoind on port 4444 is to create a new root entropy key with the command

```./gradlew run --args='-s localhost:4444 -c generate-entropy'```

This specifies a connection to `localhost` on port `4444` and the commaned `generate-entropy`

If this works, you'll recieve a 256-bit key, encoded as a hex string that might look like this `7ecaf368fa0ce478987b33acd7f9fc9b8b7dacf05a8205668700772e11f98a8d`

Rather than run all the commands using `gradlew`, you can build a distribution using `./gradlew distZip` which will build a usable binary. You can also get the distribution `mob_client.zip` from the releases page.

To track the transactions in your account, you can add a monitor for this key. A monitor continually scans the ledger for transactions that belong to a key over a large range of subaddresses. The `monitor` command will tell mobilecoind to track a specific key.

```./mob_client -s localhost:4444 -c monitor -e 7ecaf368fa0ce478987b33acd7f9fc9b8b7dacf05a8205668700772e11f98a8d```

This will return a monitor key, which is also a 256-bit hex encoded key:

`3371207b834e40d9af2c16e762598d7a4e76c4c2d46f90038a374a8bfdff2c80`

The monitor is now active and will take care of tracking all incoming and spent transactions. You can use this monitor ID to check
the balance for both the key and specific subaddress index:

```./mob_client -s localhost:4444 -c balance -m 3371207b834e40d9af2c16e762598d7a4e76c4c2d46f90038a374a8bfdff2c80 -i 0```

Of course since this is a freshly generated account key the balance will be zero. We will be distributing test coins to those
who are interested in helping us with the testnet.

To recieve a payment you'll need to generate a request code (or public address) using the `request` command which you
can then share with with someone else.
```./mob_client -s localhost:4444 -c request -m 3371207b834e40d9af2c16e762598d7a4e76c4c2d46f90038a374a8bfdff2c80 -i 1```

Every key and subaddress index has a unique code. These are represented as b58 encoded strings and include a checksum so
they will not accidentally be mistyped, e.g.:

```3WkD1Caa5XtfogSX1k7tRpq7BUCLSgZdfhjXcZHYV9oj68G3ebjkRwqe8HvSeCobD2iEnAib8VssosjwXDE6btSGMXZ3pQnmKGWGqwSaJvLwWo```

You can use this request code to transfer between your own subaddress indices, or you can give it to someone else and
have them send you a payment using the `transfer` command:

```./mob_client -s localhost:4444 -c transfer -m 3371207b834e40d9af2c16e762598d7a4e76c4c2d46f90038a374a8bfdff2c80 -i 0 -r 3WkD1Caa5XtfogSX1k7tRpq7BUCLSgZdfhjXcZHYV9oj68G3ebjkRwqe8HvSeCobD2iEnAib8VssosjwXDE6btSGMXZ3pQnmKGWGqwSaJvLwWo -a 50000```

This will print a `reciept` which you can use to check the status of your transfer using the `status` command:

```./mob_client -s localhost:4444 -c status -r 1ad7dfb8a36a637d717aa7b272e49ce05d267ad1927898b7f2b5b9a40306a443:116```


This code serves both as an example of how to use the services provided by mobilecoind
in Java through gRPC and as a CLI tool to interact with mobilecoind.

Java SDK


The MobileCoin Block Daemon, or `mobilecoind`, is a standalone executable which provides blockchain synchronization and wallet services.

It creates encrypted, attested connections to validator nodes who are participating in federated voting in order to get the current block height, block headers, and to submit transactions. These validator nodes are considered highly trusted due to their use of SGX, and they are used as a reliable source for block information as well as to validate and process the proposed transactions from `mobilecoind`.

To keep the blockchain in sync, `mobilecoind` downloads new blocks from cloud storage and checks with the validator nodes that the block headers are correct. If this succeeds, they are added to a local copy of the blockchain called the Ledger DB. This is done periodically and ensures the local copy of the blockchain is fresh enough to calculate balances and generate transactions.

Wallet Clients, such as a CLI, wanting to use wallet services can register their keys through the [API](./api/proto/mobilecoind_api.proto). In addition to keeping the blockchain in sync, the MobileCoin Daemon maintains a list of unspent transactions owned by any registered keys for fast lookup and spending, in a database called the MobileCoin Daemon DB.

## Table of Contents

  - [Getting Started](#getting-started)
    - [Setup](#setup)
    - [Verifying Signed Enclaves](#verifying-signed-enclaves)
    - [Example Invocation](#example-invocation)
    - [Offline Transactions](#offline-transactions)

### Getting Started

#### Setup

In order to sync the ledger from multiple sources, you will need to specify the validator nodes that you trust, as well as the location where they publish their externalized blocks (this is typically an S3 bucket).

We use URIs to specify peers, such as:

```
mc://node1.test.mobilecoin.com/
```

You will need to specify a ledger location to which to sync the ledger. This directory can be empty (or non-existent), or can contain the origin block, created from [generate-sample-ledger](../util/generate-sample-ledger/README.md).
You will also need to specify a directory for the MobileCoin Daemon database, where keys and transaction data would be stored.

#### Verifying Block Signatures

When started with `--watcher-db`, mobilecoind syncs all block signatures from the consensus validator archives listed in the tx-source-urls. On sync, each block signature is verified. See the [watcher](../watcher/README.md) crate for more information.

#### Verifying Signed Enclaves

When mobilecoind connects to validator nodes, it verifies the integrity of their software using Intel's Secure Guard eXtensions (SGX) via attestation evidence.

The validator node provides a signed measurement of its internal state to assure that it is running exactly the software you expect. You must provide a specific file to mobilecoind on startup so that it has the materials it needs to validate the enclave's evidence.

The TestNet signature artifacts are available via

```
curl -O https://enclave-distribution.test.mobilecoin.com/production.json
```

This retrieves a json record of:

```json
{
    "consensus": {
        "enclave": "pool/<git revision>/<signing hash>/<filename>",
        "sigstruct": "pool/<git revision>/<signing hash>/<filename>"
    }
}
```

The git revision refers to the TestNet release version, and provides the full path to the production version of the artifact.

For example, MobileCoin's TestNet enclave signature materials are available via:

```
curl -O https://enclave-distribution.test.mobilecoin.com/pool/bceca6256b2ad9a6ccc1b88c109687365677f0c9/bf7fa957a6a94acb588851bc8767eca5776c79f4fc2aa6bcb99312c3c386c/consensus-enclave.css
```

Once you fetch the sigstruct artifact, you must provide the sigstruct to mobilecoind via the environment variable `CONSENSUS_ENCLAVE_CSS=$(pwd)/consensus-enclave.css`.

#### Example Invocation

This invocation connects to two validator nodes in the MobileCoin demo network, uses their respective S3 buckets to download new blocks, polls every second for updates and provides a MobileCoinD API on port 4444.

>Note: The MobileCoin Daemon validates attestation evidence from the validator nodes, and so needs to know whether those validators are running with hardware SGX or in simulation mode, via the `SGX_MODE` variable. In addiiton it needs to know whether the enclave was built in debug or relase, via the `IAS_MODE` variable.

```
SGX_MODE=HW IAS_MODE=PROD CONSENSUS_ENCLAVE_CSS=$(pwd)/consensus-enclave.css \
    MC_LOG=debug,rustls=warn,hyper=warn,tokio_reactor=warn,mio=warn,want=warn,rusoto_core=error,h2=error,reqwest=error \
    cargo run --release -p mc-mobilecoind -- \
    --ledger-db /path/to/ledger \
    --watcher-db /path/to/watcher-db \
    --poll-interval 1 \
    --peer mc://node1.test.mobilecoin.com/ \
    --peer mc://node2.test.mobilecoin.com/ \
    --tx-source-url https://s3-us-west-1.amazonaws.com/mobilecoin.chain/node1.test.mobilecoin.com/ \
    --tx-source-url https://s3-us-west-1.amazonaws.com/mobilecoin.chain/node2.test.mobilecoin.com/ \
    --mobilecoind-db /path/to/mobilecoind-db \
    --listen-uri insecure-mobilecoind://127.0.0.1:4444/
```

For more details about the various command line arguments supported by the MobileCoin Daemon, use the `--help` argument:
```cargo run --release -p mc-mobilecoind -- --help```

#### Offline Transactions

Offline transactions are a way of constructing a transaction on a machine that is not connected to the Internet, allowing for increased safety around the storage of sensitive key material. The requirements for doing that are:
1. A machine that is connected to the internet, running `mobilecoind` as usual.
1. A second machine, not connected to the internet, that has a recent copy of ledger. The ledger must contain some spendable TxOuts by the key that will be used.

The steps for constructing and submitting an offline transaction are:

1. Copy a recent copy of the ledger database into the airgapped machine. The copied ledger should include TxOuts that are spendable by the user.
1. Copy the pre-built mobilecoind binary to the airgapped machine.
1. Run `mobilecoind` on the airgapped machine: `MC_LOG=trace ./mobilecoind --release -- --offline --listen-uri insecure-mobilecoind://127.0.0.1:4444/ --mobilecoind-db /tmp/wallet-db`.
1. Connect to this `mobilecoind`, add a monitor with your keys, let it scan the ledger, and construct a transaction using the `GenerateTx` API call, using one of the clients such as `mobilecoind-json`.
1. `GenerateTx` will return a `TxProposal`, which you can then copy back to the internet-connected machine.
1. Copy this `TxProposal` into a machine that has internet access and `mobilecoind` running.
1. Decode the `TxProposal` and submit it using the `SubmitTx` API call. Even if the `mobilecoind` instance you are submitting to has no monitors defined at all, this would still work.


The MobileCoin Block Daemon, or `mobilecoind`, is a standalone executable which provides blockchain synchronization and wallet services.

Full Service API

Show Me the Code

What's your email?