When you add a trust line, the minimum required balance of the account increases by 1 x base reserve. In order to hold a trust line in your new account, it would need a balance of 1.5 XLM.
From the documentation on minimum account balance:
All Stellar accounts must maintain a minimum balance of lumens. Any transaction that would reduce an account’s balance ...
It is possible to decode XDR objects by using the stellar_base.stellarxdr module.
from stellar_base.stellarxdr import Xdr
result_bytes = base64.b64decode(response['result_xdr'])
tx_result = Xdr.StellarXDRUnpacker(result_bytes).unpack_TransactionResult()
To get a hold of the contents as readable text:
p = jsonpickle.Pickler(keys=True)
You can not determine trustworthiness in an automated way, you have to personally decide if you trust a counterparty. Worst thing to happen is, that you trust a scammer, insolvent or (if they lose the backed anchored asset for any reason) incompetent company and the tokens you buy/hold on that trustline are actually worth nothing.
Your trust lines are ...
Step 1: Set the authorization required flag for your issuing account (?), this way nobody can create a trustline for your asset without your authorization.
Step 2: Require users to set a limit when creating a trustline. That's the second parameter in the CreateTrust operation. That is the maximum amount of asset tokens that their account may ...
Steve, just sent you 1 SLVR (1 gram of silver) to your accept all address.
Receiving an asset without a trustline is not possible on the network level.
However, when you make a payment to accept all address, the funds are actually sent to this escrow account, which has most of the trustline already configured (and keeps adding them automatically).
If you want x and y to trust the same asset (not issued by either x or y) then you will need an account a to serve as the issuer account.
If you want to continue to distribute tokens issued by the issuer account a after the issuer account has been locked then you will need a fourth account b to serve as the distributor account, which initially holds all ...
The SDK reference documentation is built automatically from the sources using JS Doc format parser, so it doesn't contain the detailed information and usage examples, only methods descriptions extracted from JS Doc comments.
You'll find practical use cases with line-by-line comments here.
The operations-for-account endpoint will list all operations for that specific account incl. changes to the trustlines.
If you scroll to the bottom on this stellar laboratory page (after clicking submit) it will show you the following operation which changed the authorize flag to false:
The distribution account (b in your case) is optional. It is handy in most cases, because asset issuing logic can be fully separated from the distribution/trading/ICO logic.
You can send your asset issued by a account directly to accounts x and y without any mediators. When you send custom asset from the issuing account to any other account, it issues an ...
Yes, it's possible.
You can have multiple issuers issue assets with the same asset code. In order to achieve this, the "count collector account" would need to create trustlines for the same <asset_code> issued by each of issuer accounts. Then the issuer accounts can just send that <asset_code> (issued by themselves) to the count collector ...
I'm not sure which SDK you are using but the trustor should be the account setting the trust line and in the python SDK the trustee is specified in the asset definition which is Asset(symbol, issuer_public_key) so it does not need to be specified separately.
Because the allow trust operation is created by the asset issuer, the trustee is implied, but the ...
Let's say you want to merge account X to account Y.
X cannot hold any offers or trustlines (therefore, no assets), according to the source code.
Otherwise, the operation will fail with "op_has_sub_entries".
And account X will be charged 100 stroops ...
To make your case work:
First, use accountB to trust "ASTRO"(issued by accountA), and sign with accountB. This means that now accountA recognizes ASTRO.
Then, you may send this ASTRO(by accountA) freely to accountB.
On Stellar, there is an operation [Change Trust] that allows a user to "trust" an asset (or the other way, revoke the ...
A Stellar Asset is differentiated primarily based on the Issuer. Hence changing Issuer is like creating a new asset on its own. So it is not NOT possible to change the Issuer.
But, you can create a new Asset with the same name and launch an application that can facilitate 1:1 swap with old asset to new asset, easily.
Since the asset issuing account is determined by the ID of the account that physically created the asset, there wouldn't be any way to "change" who issued an asset.
The only solution I see is to issue a new asset with the other address, and have previous trusting addresses open a trustline with the new asset.
You can put multiple operations for different accounts (identified by the 'source' parameter in each operation) into the same transaction. If one operation fails then all operations will fail. Instead of sharing secrets, share the transaction and let everyone append their signature. XDR representation is the way to share a transaction.
// tx object to xdr
Good timing! In the upcoming Horizon release (0.23) we added trustlines filtering. From the doc:
This endpoint allows filtering accounts who have a given signer or have a trustline to an asset. The result is a list of accounts.
To find all accounts who are trustees to an asset, pass the query parameter asset using the canonical representation for an issued ...
The person you are trying to send a token to has to set a trustline himself (with a change trust operation) to your issuing account. If his exchange wallet does not allow for it then he will have to use a different wallet that allows him to set trustlines.
From the technical point of view, after the first COOLTOKEN ICO wave you can issue another token, say, COOLTOKEN2, sell it and then exchange COOLTOKEN2 for COOLTOKEN at 1:1 rate.
But turning off trustlines authorization after the tokensale defeats the whole idea of KYC. You will definitely have troubles with regulators after such move. If you don't care ...
Trustlines, Offers, Signers, and Data Values are called subentries. Each subentry locks 0.5 XLM from your account for the min_reserve.
When you remove a subentry from your account, the corresponding XLM balance is unlocked and you can use it. This is described in more detail here, quoting:
Minimum Account Balance
All Stellar accounts must maintain a ...
If I understood your question correctly, you are asking about the account <-> trustline relation. A trustline is related directly to the account that establishes the trustline, not the asset issuer account. That's why an issuing account details does not contain any balance records for the issued assets (for example, see Mobius issuing account details). ...
The issuer/anchor will have to figure out a process for that, and it can vary significantly depending on their compliance process.
For example, an anchor may require a customer to register on their website providing KYC information (along with their stellar address), and if everything checks out, they'd execute the Allow Trust operation on the address.