Xfer - Safe Transfers Tutorial

in HiveDevs7 months ago (edited)

Yesterday, I introduced Xfer, a powerful tool designed to perform asset transfers on the Hive blockchain securely and with complete peace of mind. If you missed it, you can click here to read the introduction post.

In this beginner-friendly tutorial, I will walk you through the two essential steps of using Xfer: Managing Routes and Executing Transfers.

I will also provide additional information regarding costs associated with its use as well as important safety considerations.

Managing Routes

Managing routes with Xfer is the first crucial step to ensure your transfers go smoothly.

Route management is performed by sending a micro-transfer of either 0.01 HIVE or 0.01 HBD to the @xfer account with a structured memo containing command and parameters.

Note: Keep in mind that the asset you use for your transfer determines the type of route you manage:

  • If you send a command using HIVE, you will manage an HIVE route.
  • If you send a command using HBD, you will manage an HBD route.

Each command sent to Xfer may require one or more of the following parameters:

{"cmd":"[command]", "route":"[name]","target":"[recipient]","memo":"[memo]"}

ParameterDescription
[command]A route management command
[name]An easy-to-remember route name.
[recipient]The final recipient for your transfer (without the @)
[memo]
(optional)
A memo you want to send to the recipient. If prefixed with #, the memo will be encrypted.

1. Creating a route

To create a new route, initiate a micro-transfer to @xfer using the following structured memo:

{"cmd":"ADD", "route":"[name]","target":"[recipient]","memo":"[memo]"}

If a route with the same name for the same asset already exists, @xfer will send you back en (encrypted) error message.

Examples:

  • {"cmd":"ADD","route":"binance","target":"deepcryto8","memo":"123456789"}
    creates a route named "binance" to send assets to the account @deepcrypto8 with the memo "123456789"

  • {"cmd":"ADD","route":"arcange","target":"arcange" }
    creates a route named "back" to send assets to the account @arcange without memo

  • {"cmd":"ADD","route":"secret","target":"arcange", "#an encrypted memo" }
    creates a route named "secret" to send assets to the account @arcange with a memo that will be encrypted

Here is a screenshot of such a transfer made using peakd.com. You can of course use any other front-end or wallet app.

1. The recipient is @xfer
2. we send a small amount
3. we send HIVE -> this will create a "HIVE route"
4. the command is put in the memo. As the command is prefixed with #, it will be encrypted when sent.

2. Updating a route

To update an existing route, initiate a micro-transfer to @xfer using the following structured memo:

{"cmd":"UPD", "route":"[name]","target":"[recipient]","memo":"[memo]"}

If the route doesn't exist, @xfer will send you back an (encrypted) error message.

Example:

  • {"cmd":"UPD","route":"binance","target":"bdhivesteem","memo":"789654321"}
    updates the previously created "binance" route and changes the recipient to @bdhivesteem as well as the memo

3. Deleting a route

To delete an existing route, initiate a micro-transfer to @xfer using the following structured memo:

{"cmd":"DEL", "route":"[name]"}

Example:

  • {"cmd":"DEL", "route":"binance"}
    deletes the previously created "binance" route

To delete all routes at once, both HIVE and HBD, initiate a micro-transfer to @xfer using the following structured memo:

{"cmd":"CLR"}

4. Listing all existing routes

To retrieve the list of all the routes you created, HIVE and HBD, launch a micro-transfer to @xfer using the following structured memo:

{"cmd":"LST"}

@xfer will send you back an (encrypted) memo with all the routes you created. The routes returned will be both HIVE and HBD routes.

Additional considerations about route management

  • With the exception of the [memo] parameter, all content is case insensitive. This means that a structured memo like
    {"cmd":"ADD", "route":"demo","target":"username","memo":"A Memo"}
    will be treated in the same way as:
    {"CMD":"add", "Route":"DeMo","TargeT":"USERname","MEmo":"A Memo"}

  • When sending commands to @xfer, you can choose to encrypt the structured memo separately from the memo sent to the final recipient. This added layer of security enhances the privacy of your interactions with Xfer. To do this, simply prefix your memo structure with a #

    Example:
    #{"cmd":"ADD","route":"binance","target":"deepcryto8","memo":"123456789"}

    In the above example, only the structured memo will be encrypted, not the one sent to the final recipient (@deepcrypto8)

Executing Transfers

Once you've set up your routes, executing transfers is a breeze.

Verifying your routes

While Xfer offers safeguards, the ultimate responsibility for your route configuration lies with you!

Therefore, before executing any transfer involving a large amount of tokens, carefully review the routes you've configured.

Making your first transfer with a very small amount is a good idea. If it goes without a hitch, then you can perform the following transfers with complete confidence.

Sending money

To make a transfer, simply send your assets to the @xfer account with the proper routing code in the memo. Xfer will validate your code and, if correct, execute the transfer following your predefined route.

In case of any issues, such as utilizing an unknown route, the funds will be promptly refunded to you. You'll receive an error message in the memo, detailing the nature of the error for clarity.

Example:

Let's consider the account @arcange.pay has created a route by sending HIVE to the account @xfer with the following memo:

@arcange.pay then execute the following transfer:

Here's what happens next:

You can see that the @xfer account has received 1 HIVE from @arcange.pay with a "demo" memo. As there is an existing "demo" route, @xfer forwards them to the final recipient (@arcange) and the memo that was defined in the route.

Minimum amounts and fees

Hive operates on a system of resource credits that are consumed during transactions. Therefore, measures have been implemented to prevent malicious actors from draining resource credits from the @xfer account and taking down the service.

It's essential to be aware of the minimum amounts when utilizing Xfer.

  • Route Management
    The minimum amount to send to @xfer is set at 0.01 HIVE or 0.01 HBD.
    This means that any transfer below this threshold will NOT trigger any action from Xfer and will be considered a donation to the service.

  • Transfers
    A minimum of 1 HIVE or 1 HBD is required.
    Additionally, a fee of 0.1% is applied to the transfers, with a maximum fee capped at 1 HIVE or 1 HBD.

The minimum amounts and transfer fees are a safeguard to maintain the stability and availability of the Xfer service for all users.

Safety considerations

Not Mandatory but Trustworthy Choice

Using Xfer for your transfers is not mandatory, but it's a choice rooted in trust and convenience. While it offers remarkable benefits, trust in the Xfer service operator is essential, as they play a pivotal role in ensuring the security of your transfers.

Exchange Transfers

When transferring funds to exchanges, it's vital to note that the sender will appear as @xfer, not your personal account. This distinction can complicate the recovery process in the event of a route error.

Therefore, it's sage advice to consistently double-check and rigorously test your routes, preferably with a small token amount, before committing to extensive transfers. This precautionary step ensures that you're well-prepared for a seamless and error-free experience when it matters most.

Empowerment Through Open-Source

If placing trust in a third party isn't your preference, Xfer will offer an empowering alternative. The code of Xfer will be open-sourced and you will have the option to run your own Xfer service. You will then be in charge of the full transfer process.

Conclusion

With a comprehensive understanding of Xfer's capabilities and considerations, you are now well-equipped to harness the power of this service for your asset transfers.

Remember that Xfer is a reliable tool at your disposal, ready to facilitate your transactions. It's been designed with both convenience and security in mind, offering the means to execute asset transfers on Hive with confidence.


The Xfer service is ready for you to use!

Documentation is available at https://docs.hivexfer.com
Support is provided on Discord


Check out my apps and services


Vote for me as a witness

Sort:  

Thanks have shared and bookmarked to remember the steps!

Interesting and useful tool!
@tipu curate

Nice tool!
Thanks for your work @arcange !

Thanks for the detailed instruction!

!PIZZA

You're welcome @irisworld
!BEER

PIZZA!

$PIZZA slices delivered:
@irisworld(3/5) tipped @arcange

Saw this on the HF presentation but missed the announcement post, will check it out. Sounded like a good idea, though I wondered how it could be made easier. Do you think future smart contracts on Hive might make this service even more secure from 1 point of entry attacks? (even though I realize the tx's happen close to instantly, there could be a time when you're not around and someone may have gained access and steals all funds until it becomes clear to everyone what's happening)

I wondered how it could be made easier

The next step will be to create a small website to help users create and send their route management commands.

Do you think future smart contracts on Hive might make this service even more secure from 1 point of entry attacks?

You bring up an important point regarding security. It's been part of the Q&A that happened during my presentation at HiveFest.
While Xfer is designed to be secure and efficient, its implementation in a smart contract, or even better at the blockchain core level, may enhance its security.
However, as you rightly pointed out, transfers happen almost instantly which makes it difficult for anyone to misuse it.
And as long as I'm the one in charge of it, I don't think anyone else can take control of @xfer and its service.
I don't claim that this is an ideal solution, but for many it comes close.

In any case, I am always looking for ways to improve and evolve the service.

I've always wanted @peakd to support an address book for verified receipients. If I am sending a large transfer, I'm going to make sure it is right, not send it to a third party that I will trust to send to a third party.

This is cool
Thank you very much for the information

"If placing trust in a third party isn't your preference, Xfer will offer an empowering alternative. The code of Xfer will be open-sourced and you will have the option to run your own Xfer service. You will then be in charge of the full transfer process."

When you introduced the Xfer service I did not note this possibility. While I do not mean to imply anything about you, I have been financially harmed by trust in fiduciaries in the past, so the necessity of trust in a fiduciary for the functioning of the Xfer service gave me pause.

I am greatly relieved to see you have anticipated that issue, which is, after all, the foundation of cryptocurrency itself.

Thanks!

I totally understand your concerns and that's why I decided to make Xfer open-source. It's all about providing options and empowering users.

I'm sorry that I missed the background here. Looks like a smart contract that is less expensive and faster than using Ethereum. But, I don't get the utility of a transfer service that requires a transfer to begin with. I'm sure there is a need. What is it, if you would please?

The main utility of Xfer is to provide a secure and convenient way to transfer assets.
When you make a transfer, there's a risk of making typos in the recipient's username or the memo field, especially when dealing with exchanges where a correct memo is required. With Xfer, you can set up predefined routes with the right recipient and memo. This way, you only need to remember your route name when making transfers.
This is particularly useful for users who regularly send funds to specific accounts or exchanges.

An application like Xfer could also function, be implemented, without receiving user funds, in which case it would be safer.
How? if Xfer app would act as a API node, users would broadcast transactions to it and it would act as a filter not broadcasting transaction that are deemed to be sent to wrong address.

I appreciate your suggestion and it's definitely an interesting approach.

However, this would require users to trust the Xfer node for broadcasting their transactions, which could raise other security and privacy concerns. Moreover, it would require significant changes in many applications and services interacting with the Hive blockchain, as they would need to be updated to interact with this specific node for transfers.

The current implementation of Xfer provides a balance between security, ease of use, and compatibility with all existing Hive interfaces. It allows users to leverage the service using any application that can interact with the Hive blockchain without requiring any changes on the application side.