We recently made 3 updates to the SOV contract in preparation for locking and live trading. These updates were made to increase the flexibility of SOV and give it the ability to integrate into existing and future dApps and services with ease after the contract is locked.
- Update default SOV transfer
Now, whenever a transfer is executed, the burn is taken from your SOV account balance instead of the transaction. This means that what you send is exactly what the other party will receive.
Example for current stage.. Person A sends 1000 SOV with the default transfer. 1001 SOV is subtracted from their balance, 1 SOV is burned, and the receiver gets 1000
This means if you try to send your whole balance you will get an error message since the burn is in addition to the amount transferred. However, this is not an issue since the error message will tell you the maximum you can send with current burn rate.
This update was made for User Experience and Exchange integration. This ensures the amount sent and received are identical and eliminates the need to do any math to ensure the receiver gets the exact number of SOV they need (ideal for most transactions and sending payments for goods / services).
2. Add SOV xTransfer action
The xTransfer is exactly how it was previously set up and is nothing new aside from the name. You can send your entire balance with xTransfer, because the burn comes out of the amount sent and the receiving party gets less.
Example for current stage.. Person A sends 1000 SOV with xTransfer. 1000 SOV is subtracted from their balance, 1 SOV gets burned and the receiver gets 999.
This was added as a separate, non-default transfer action because some dapps and exchanges will need this type of functionality for their contracts, though most of the time the default transfer will be best. Some services and contracts are set up in a way that will only make sense to accept default transfers and send out xTransfers. Others may choose to do only one or the other for convenience sake. The important thing is dapps will have the flexibility to choose what works best for their situation and / or smart contract.
Only use the xTransfer for P2P transfers unless specifically told otherwise by the dApp or service you are using.
3. Send burn receipts exclusively to themintofeos with transaction hash
Automatic notifications to three parties for every single transfer / xTransfer action can be problematic for certain contracts. It also creates a lot of clutter that not all may want. Because of this, we have condensed burn receipts to themintofeos.
Whenever you make a transfer or xTransfer, you will be able to look up your hash / transaction number and search themintofeos in a block explorer to see all the exact details of your transfer, including amount sent, received, burn stage, burn rate, etc.. This way all receipts are available to all at any time without clutter and without creating problems for certain types of contracts.
Join the SOV telegram https://t.me/eossov for more information and to get involved with the community.
If you haven’t already, you can read the white paper and project summary at https://soveos.one
If you have an EOS Genesis account, you can claim your free SOV at https://eossov.one , https://eostoolkit.io/airgrab , or https://bloks.io/wallet/airgrab
