Stellar offers path-payment.
This means that an user can trade ASSET1 directly to ASSET2 in 2 case:
There is a specific trading pair ASSET1/ASSET2 in Stellar Decentralized Exchange
There is a "trading path" available for the 2 asset specified (ASSET1/ASSET_X -> ASSET_X/ASSET2)
You can look to official documentation and found an example that directly ...
One reason would be a change in dollar value of a lumen. At the time when the base reserve was set to 10XLM, the 20XLM necessary to open an account amounted to well under one dollar. At the current price, it is $10, which some people find is too high. The same goes for the base fees.
The other two answers are totally correct, but I wanted to add some color.
Technically, you can create a path payment in Stellar to trade assets using any bridge, but generally you need to use a bridge asset that has some kind of value. So, just issuing an asset randomly and "putting it out there" would technically function as a bridge, but what does that ...
I've asked a similar question on Slack a few months ago. After digging in the Stellar Core sources, I figured out that the fee is considered when Core decides what transactions to include into the next ledger.
It seems to me that the only situation when supplying larger fees may be handy is a period of loading spikes, when users submitted more than 50 ...
The only spam protection currently in place is the transaction fee of .00001 XLM. This is very cheap, and doesn't totally prevent spam, as we saw in the case of the recent stellarpool spam. It is, however, (hopefully) enough to make it somewhat expensive to spam the network enough to cause congestion.
The voting is done via online communication between those who run nodes, the final change is voted on using the consensus protocol.
Validators are the people/nodes that comprise the Stellar Network that vote on the network. You can be a node on the network but not have voting privileges. You can be a node on the network, but exclusively watching -- these ...
You can trade any asset for another when a matching offer exists.
It is also possible to do cross-asset payments with up to 6 different hops.
This process of finding the best path of a payment is called pathfinding. Pathfinding involves looking at the current orderbooks and finding which series of conversions gives you the best rate. It is handled ...
The account merge operation does that.
I don't know any wallet that supports it, but an easy way to do it without programming is stellar laboratory
If there are any other assets move them with regular payments first.
Go to stellar laboratory transaction builder
Enter the account you want to have removed as "Source account"
Click on "Fetch sequence number......
Transaction fees are calculated over the number of operations into a transaction
Each operation "costs" a base fee (currently* 100 stroops -> 0.00001 XLM) regardless of operation type or operation content
So if you have a transaction with only one payment operation, you will always* pay 0.00001 XLM. This apply both if you send 100XLM or 1B XLM
More info ...
You can read the network configuration section in the admin guide.
Here is the relevant snippet:
For a new value to be adopted, the same level of consensus between nodes needs to be reached as for transaction sets.
What that means is that the mechanism (consensus) to get the network to agree to a change is the same one than for deciding which transaction ...
As far as I can understand it from the feature description, it has nothing to do with the lightning network.
The only effect from the mentioned operation is a bump (increment) of the account sequence number, which can be useful for complex use cases.
A typical use for this is to allow invalidating large ranges of transactions that were pre-shared with ...
Many(most?) anchors have withdrawal fees, including apay.io (https://apay.io/out).
Another possibility is working with other businesses and charging them a fee to use it - but this is probably more common with fiat anchors.
There is no official policy. When a need arises, the community (of validators) can discuss the issue and decide whether they want to make a change or not.
To answer your other question, the reserve cannot be safely raised. If it were raised, any account with the current minimum would not function anymore.
Actually Stellar doesn't choose a path. You (or the software you use) are supposed to define one.
You can actually check various orderbooks and compute the cost to find the best path. You find the conversion rate by finding which offer your operation would match. You can derive the fee by comparing how much the destination asset will cost you against its ...
There is no way to send lumens directly on the Stellar Network without the sender paying the fee. This fee is built directly into the Stellar Network.
"Stellar deducts the entire fee from the transaction’s source account, regardless of which accounts are involved in each operation or who signed the transaction."
As Ben Ayles has said, currently the only spam protection in place is the transaction fee. This subject has been discussed a few times on Reddit.com. Notable ideas to combat this include filtering them out at the wallet level and the addition of stealth addresses.
Actually, there's an informal official policy:
The base reserve and base fee can change, but should not do so more than once every several years. For the most part, you can think of them as fixed values.
Stellar has a fixed base fee.
You can calculate the expected fee with this formula
(# of operations × base fee)
where base fee is 100 stroops. See the docs.
Nobody can earns XLM from his validator because all fees goes into the fee pool, and then these lumens are distributed by inflation pools.
Stellar use a different consensus protocol, ...
The transaction fee is deducted from the account that acts as the source account for the transaction envelope.
const account = await server.loadAccount(source);
const builder = new stellar.TransactionBuilder(account)
The gist of what SDF Core developers commented on the issue:
It turned out that presently the testnet is always in the fee surge pricing mode because the condition if (operations > ledgerHeader.maxTxSetSize-100) will be always true (current ledger max_tx_set_size is 100) if at least one transaction is included into the ledger. So, for example, if you ...
Change the name of the native currency
It's always native in the Horizon server response, but you can name it as you like in the interface. I guess that if you are going to create a separate chain, you'll create a custom client as well, so this shouldn't be a problem.
Change the number of native currency created in the first block to 1000
When you create ...
One workarounds for this case is:
Set "authorization required" for your asset but don't allowTrust to any user in general. Instead require them to sandwich every payment + payment fee operation between a allowTrust and a allowTrust(revoke) operation. This way your authorization (by co-signing every transaction with the asset issuer account) for using that ...
Using your example, in order to withdraw EUR from Anchor2, you will need to trade your Anchor1:USD for Anchor2:EUR on the distributed exchange (SDEX).
The cost will be the exchange rate of that trade, less the minuscule fee for issuing transactions (paid in XLM).
Additionally, an anchor may apply a fee when you deposit or withdraw fiat. I am not familiar ...