When you first download Tari Aurora, you’ll receive some tXTR from the faucet bot. If you want more, ask your friends to send you some or try mining testnet Tari. Learn more about mining testnet Tari.

This means the transaction is being processed on the Tari network, which usually takes no more than a couple of minutes.

Sending a transaction from Tari Aurora is simple and intuitive, but under the hood there’s a lot going on. A lot.

To give you an idea of what happens between you clicking “send” and the transaction being confirmed on the blockchain, have a look at this article explaining how Tari transactions work.

In case that’s tl;dr, here’s what happens every time Alice sends Tari to Bob. Remember that there are no servers or centralised parties that are able to co-ordinate these communications! Everything is done on the peer-to-peer network.

1. Alice taps “send”.
2. Alice’s wallet selects which coins to spend, creates her change, and determines the network fee. It then builds her half of the transaction. At this point, her wallet will display “Waiting for recipient to come online”.
3. Alice’s wallet then needs to find Bob’s wallet on the peer to peer network. It does this by
   1. Checking to see if she already knows Bob,
   2. If not, asks some of her peers if they know Bob.
4. Alice’s wallet will then try and establish a connection to Bob directly.
5. If Bob responds, Alice sends over her half of the transaction.
6. Bob’s wallet will check that the transaction looks legit, and then fill in his part of the transaction, sign it, and then try and send it back to Alice. At this point, Bob’s wallet will say “Waiting for sender to complete transaction”.
7. If Alice is still online and receives Bob’s reply, she’ll check that the transaction still checks out, signs it and then attempts to broadcast the transaction to the blockchain network.
8. Alice’s wallet sends a courtesy message back to Bob to say that she’s done this. Now both wallets update the transaction status to say “Completing final processing”.
9. Once the transaction has been mined and is included in the blockchain, it can be marked as complete. Both wallets need to periodically ask a base node whether the transaction has been mined yet, in order to know whether that last step has happened.

When this goes smoothly, the transaction negotiation completes in under a second, and then it takes roughly two minutes to get confirmed. But there are at least a dozen points in that flow where things can be disrupted.

• If either Alice or Bob go offline at any point in the above flow, or
• if either run iOS and put the app in the background, or
• if there’s a problem with the Tor client making a connection to the network, or
• the blockchain is congested and the transaction is not mined immediately, or
• the blockchain is congested, the transaction is not mined immediately, and then it falls out of the mempool (the network forgets about it), or
• Alice tries a double spend, or
• The base node that the wallets are polling goes offline, or has stopped responding for some reason, or
• There’s a bug in the wallet or base node code that is affecting the usual harmonious flow.

If any of these things happen, the process pauses until the issue resolves and the flow can continue. This is where you’ll notice that a transaction appears to be “stuck”.

Luckily, the Tari devs have anticipated a lot of these issues and have put additional safeguards in place to try and keep the flow moving as smoothly as possible.

For instance, if Bob is suddenly unreachable in steps 4 and 8, then Alice’s wallet will ask some of Bob’s peers (Charlie and Dave) to keep the message for him, and deliver it when he appears again. Now, if Alice goes offline, at least Bob will still get the message and the flow can limp forward.

The same thing happens when Bob tries to send messages back to Alice in Steps 5 and 6.

The Tari Aurora wallet also has a small database of base nodes it uses to poll in Step 9, so if one of those nodes stops responding, Tari Aurora will try another one.

The wallets will also detect if the network has forgotten about the transaction for some reason and resubmit it.

All in all, in a system that has so many moving parts and requires careful choreography for things to go right, with no central party directing the steps, it’s fairly impressive that transactions get mined at all.

The Tari peer-to-peer network does a great job in building lots of robustness into the system, but from time to time, things can and do go wrong.

If your transaction has been stuck “in progress” for a long time, there are a few options available to you.

As sender

If you are the sender, and the status is “Waiting for recipient to come online”, then you can choose to cancel the transaction. It’s possible that the recipient is never going to countersign the transaction, so you can free up the funds locked up in this transaction and then try again at a later stage if you wish. The transaction has never been broadcast to the network, there’s no chance of this transaction ever completing and so your funds are perfectly safe.

If the recipient hasn’t replied within 3 days, then Tari Aurora will cancel the transaction automatically.

Once the transaction says “Completing final processing”, then the transaction is being broadcast to the Tari network. It will usually be mined in about 2 minutes and become finalised, but if the network is congested, or there is a sudden drop in hash rate, this can take much longer.

The wallet will periodically check to see whether it has been accepted into the mempool and then if it has been mined. The wallet will rebroadcast the transaction if it has fallen out of the mempool without being mined. At this stage, the transaction can no longer be cancelled.

As recipient

If you are the receiver, unfortunately there’s nothing you can do except wait. Until the transaction is finalised, you should never treat the transaction as complete. For example, if you’re a merchant, you should not consider payment complete until the status reflects this.

If the status does not change for three days, the wallet will discard the transaction and assume that the sender will never broadcast it to the network. This is not a guarantee however, but since you’re the recipient, there’s no real risk to you.

In principle, one could continue to scan the blockchain indefinitely looking for the output you created, but the mobile developers decided not to implement this feature on Tari Aurora to save on battery consumption.

Tari Aurora is intended to work with a wide range of Apple (iOS 13+) and Android (Nougat 7.0+) mobile devices. Found an incompatible device? Please post about it on our public Telegram so someone in the community can look into it.

Feel free to ask any questions and report bugs on Telegram.

There are no hidden third party services in the app and it strives to be as free of centralized services as possible. That said, the wallets do make use of a few services to improve the user experience for Aurora:

• The Tari testnet faucet. The faucet is a server that Tari Aurora contacts to obtain the “seed tXTR” that every user receives when creating a new wallet. Your wallet’s IP address is recorded on this server to prevent a Sybil attack from draining the faucet and ruining the experience for everyone else.
• Matomo. Matomo is used by the mobile wallet community to understand how you interact with the wallet and to identify pain points and shortcomings in the UX. Your IP address is not recorded (it is anonymized however, so that returning visitors can be identified). Some device information including operating system and manufacturer is recorded. The Matomo server that collects this data is managed by Tari Labs.
• Apple push notifications. iOS does not allow apps to remain in the background. This poses a problem for Mimblewimble-based crypto wallets and is a UX non-starter because your wallet must sign any incoming transactions before they can be broadcast to the blockchain. This would mean that an iOS app would have to be open and in the foreground in order to receive tXTR. The mobile developers decided to make use of Apple’s push notifications to alert the app whenever a transaction is inbound. This requires the running of a centralized notification server, managed by Tari Labs, as well as the routing of all notifications through Apple’s servers. To maximize privacy, these notifications carry no identifiable information at all (though Apple Inc., in theory, knows when and how many notifications a particular device is receiving).
• Sentry. Both Android and iOS Tari Aurora apps make use of Sentry to collect crash reports. The Sentry server is managed by Tari Labs.
• TTL Store. The TTL Store store is hosted and managed by Tari Labs.

All of these services and their user experience-privacy trade-offs were carefully considered before including them. However, we know that these trade-offs are different for everyone, and for that reason, it’s entirely possible to remove these services and compile a version of the wallet that works for the most part (although without push notifications, the iOS app will deliver a severely sub-optimal experience).

To help privacy-focused users out, there is a “privacy” flavor in the Android app that will easily allow one to compile a version of the wallet that excludes ALL of the services described above. Naturally, this means that you won’t receive tXTR from the faucet, be able to interact with The TTL Store, or participate in helping to improve the app.

A similar approach for the iOS app is in the works as well, so keep an eye on the updates page as to when this will drop.