<p>In general, it looks good. The way you store signing keys on the device is critical. Ideally, you want to support hardware wallets. Otherwise, make use of the OS native keystore (<a href="https://developer.android.com/training/articles/keystore" rel="nofollow noreferrer">android</a>/<a href="https://developer.apple.com/documentation/security/keychain_services" rel="nofollow noreferrer">iOS</a>).</p>
<p>You might be able to decrease the number of requests to your server when you have clients construct their <strong>signed</strong> Txs locally and have them submit to your backend. That decreases the back and forth of sending unsigned txs to the client, have them sign the Tx and submit to the backend again.</p>

CC BY-SA 4.0
2022-09-21T17:16:42.323Z
@william-berlin-pool I'll take a look into OS native keystore! I decided to export the account public key and do coin selection + fee on the server side. (I might move this to the client tough)

Thanks for helping!
Renan Valentin Ferreira
CC BY-SA 4.0
2022-09-21T19:25:23.210Z
Cool! I'd recommend having the coin selection alg implemented where the wallet lives to avoid further utxo set exchanges. 
This describes the preferred alg implementation well: https://cips.cardano.org/cips/cip2/
Will
CC BY-SA 4.0
2022-09-15T14:17:45.277Z
2022-09-15T14:17:45.277Z
Will
<p>I'm looking into creating a mobile app for learning purposes and using Blockfrost as a data provider.</p>
<p>My initial idea is:</p>
<ul>
<li>Device:
<ul>
<li>control the keys;</li>
<li>present the data;</li>
</ul>
</li>
<li>Server:
<ul>
<li>fetch data from blockfrost;</li>
<li>core application (aggregate data, construct txs)</li>
<li>notifications;</li>
</ul>
</li>
</ul>
<p>mobile -&gt; server -&gt; blockfrost</p>
<p>Mobile app will share only the <code>stakeKeyAddress</code> to the server.</p>
<p>Also, the server will construct the transactions, but the signature will be done on the mobile side.</p>
<p>Do you find any issues with this approach?</p>
<p>Many thanks!</p>

<wallet><blockfrost>
Mobile app security concerns
# Mobile app security concerns

(Asked by: username_0 on 2022-09-14)

I'm looking into creating a mobile app for learning purposes and using Blockfrost as a data provider.

My initial idea is:

* Device:
  + control the keys;
  + present the data;
* Server:
  + fetch data from blockfrost;
  + core application (aggregate data, construct txs)
  + notifications;

mobile -> server -> blockfrost

Mobile app will share only the `stakeKeyAddress` to the server.

Also, the server will construct the transactions, but the signature will be done on the mobile side.

Do you find any issues with this approach?

Many thanks!

**Tags:** wallet, blockfrost

---

## 1 answers

### Answer by username_1 on 2022-09-15. Score: 0

In general, it looks good. The way you store signing keys on the device is critical. Ideally, you want to support hardware wallets. Otherwise, make use of the OS native keystore ([android](https://developer.android.com/training/articles/keystore)/[iOS](https://developer.apple.com/documentation/security/keychain_services)).

You might be able to decrease the number of requests to your server when you have clients construct their **signed** Txs locally and have them submit to your backend. That decreases the back and forth of sending unsigned txs to the client, have them sign the Tx and submit to the backend again.

> **Comments:**
> **username_0**: @william-berlin-pool I'll take a look into OS native keystore! I decided to export the account public key and do coin selection + fee on the server side. (I might move this to the client tough)  Thanks for helping!  
> **username_1**: Cool! I'd recommend having the coin selection alg implemented where the wallet lives to avoid further utxo set exchanges.  This describes the preferred alg implementation well: https://cips.cardano.org/cips/cip2/  

---

