Jump to content


Ripple Employee
  • Posts

  • Joined

  • Last visited

  • Days Won


JoelKatz last won the day on October 2 2019

JoelKatz had the most liked content!

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Oakland, CA
  • Occupation
    Chief Cryptographer, Ripple
  • Ripple Address

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You are trying to make a payment from bank A to bank B. Both banks trust the gateway. That's not enough to make the payment possible. In this configuration, for bank A to pay bank B $100, the gateway would have to wind up owing bank B $100 since that's the only form of payment bank B has agreed to accept. But bank A has no ability to obligate the gateway ... yet. There are two ways bank A could obligate the gateway. The gateway could agree to extend credit to bank A or the gateway could give an IOU to bank A. Either way, the gateway would be agreeing to allow bank A to make the gateway owe money to bank B. The simplest way to make the payment work is this: 1. Bank A sends money to the gateway off ledger, say $500. 2. The gateway makes an on-ledger payment of $500 to bank A. 3. There is now a path for bank A to make a $100 payment to bank B as follows: Bank A returns $100 to the gateway and, in exchange, the gateway issues $100 to bank B. This is a usable payment path that will be found by pathfinding. This works because if the gateway owes $500 to bank A, then only bank A's agreement is needed for bank A to transfer $100 of this obligation to bank B. There is another way to do it that should work but is not recommend because it has some limitations. (For example, it will not work correctly with the decentralized exchange if the banks try to trade this USD for other assets.) 1. The gateway agrees to let bank A owe it up to $500. 2. There is now a path for bank A to make a $100 payment to bank B as follows: Bank A sends a $100 IOU to the gateway. The gateway has agreed to let bank A owe up to $500, so it accepts this IOU and issues a $100 balance to bank B. The gateway is now owed $100 by bank A. 3. At some point later, if desired, bank A can send $100 to the gateway in the real world. In exchange, the gateway will send a $100 payment to bank A and bank A's balance will go back to zero. This works because if the gateway is willing to let bank A borrow up to $500 from it, then bank A can choose to owe $100 to the gateway in exchange for the gateway issuing $100 to bank B. The gateway agreed to this when it extended credit to bank A. Note that the gateway must set "allow rippling by default" before the trust lines are created. This is one of the first things a gateway should do. It requires issuing an "AccountSet" transaction with "SetFlag" set to 8. Otherwise, the first scenario will fail immediately and the second scenario will fail when bank B tries to do anything (but redeeming) with the funds it received. Two broad concepts to keep in mind that may help you to better reason about what's going on here: 1. Gateways function somewhat like banks with IOUs functioning somewhat like checks. If I have $100 in the bank or the bank is willing to extend me $100 in credit, then I can write a $100 check and the gateway/bank will be willing to pay $100 to anyone who is willing to accept $100 from the bank. 2. IOUs from a source that is either trusted or that you owe money to behave like money. When you have $100 in a bank, what you have is an IOU for $100 from someone you trust. If I owe $100 to a bank, then $100 IOU from that same bank allows me to zero out that debt, which is like getting $100. Notionally, trust lines allow IOUs to flow. Payment paths chain together trust lines and order books. Reading my answer to this old question may be helpful: https://bitcoin.stackexchange.com/a/24658/85
  2. I tend to envision them as stacked, but you could envision them as one encapsulating the other. Two gets you a lot of benefit without getting absurdly complex. The key is to get the benefits of a fast, light algorithm to advance the ledger while still preserving a level of decentralization you can only get with a heavier, slower algorithm. I actually do have a design for a three-layer algorithm, but that's another story. If nothing goes wrong, the inner algorithm keeps advancing the ledger with the outer algorithm making adjustments that take place at particular ledger sequence numbers. The more complex (and hopefully very rare) case is when the inner algorithm becomes so dysfunctional that it can't make legal forward progress, in which case the outer algorithm agrees to suspend the inner algorithm and then resume at a particular point with a particular new list of inner validators. It's a bit complex.
  3. I've thought about schemes like this. The problem is that they really only work if everyone participates in fee discovery. For example, one simple scheme is to include transactions in ledgers with the same rules we currently use but to only charge the lowest of these two rates: 1. The fee level an additional transaction would have had to pay to get included in the ledger. 2. The lowest fee level paid by any transaction in the ledger. This scheme works very well when the ledger is not "full", since everyone pays the minimum, which is good. And it works well when the ledger is "full" but people really put the maximum they're willing to pay in their transactions and there's a mix of prices. But it fails in two important cases: 1. It doesn't do a good job of accommodating people willing to wait until the next ledger. You either have to choose between being charged a lot to get in the current ledger when you didn't really care about that or potentially not getting in at all. 2. It doesn't work well if everyone just uses the same fee and doesn't think through what they're really willing to pay. For example, imagine if the system is busy and all transactions come from the same wallet software that uses a default maximum fee of 0.001 XRP. Everyone will pay 0.001 XRP. But if the default had been 0.0001 XRP, that would have been what everyone would pay and the same transactions would execute. So I'm not sure that it would be a significant improvement.
  4. Yes, at least for prices of major currencies. The downside of this is that it would require validators to get a price feed from somewhere. We could use a system similar to what we use for fees where validators advertise in their validations what prices they want and then validators can combine information from other validators they trust to propose setting particular prices. The problem with this is that it will then be very hard to know where the prices are really coming from and validators might not use very high quality price sources because it takes effort on their part to do so. But we could add support to determine some prices by consensus and a stablecoin could be configured to use the consensus price. Then validator operators would have to choose to obtain prices from some source and vote them into the ledger. I'm not convinced this is worth doing, but others might disagree.
  5. Ideally, the operator would lock the price at some final value so that redemption could continue, though the asset would no longer be pegged to anything but the price of XRP itself. But there is always the possibility that the operator would stop providing a price feed. Note that while issuing and redemption would cease, the stablecoin could still be transferred and could be traded on the on-ledger decentralized exchange. People who had XRP locked up would still want the stablecoin and could place offers to buy it. So it's possible for the system to engage in an orderly wind down even if the price feed stops. A malicious price feed, however, would be a different story.
  6. Just a proposal at this point. The design is more or less complete and it's definitely complete enough that people can decide whether it's something they'd be interested in participating in. As I said in the response above, if nobody is willing to provide price feeds and operate a stablecoin, there's probably not much point in continuing to implement it. I'm trying to make sure that there's enough information about the implementation out there that people can make an informed decision of whether they'd use this functionality.
  7. It solves a few different problems. On the side of the people locking up XRP, it allows them to borrow against their XRP at zero interest while retaining full exposure to the price changes in XRP. I can also be used to obtain a leveraged long position in XRP entirely on the ledger. On the side of the people using the stablecoins, it allows them to transact as if they had XRP while being able to get whatever price exposure they want rather than only and exactly what XRP has. The most obvious case is to hold a stablecoin denominated in a currency like USD that has a relatively stable value because your use case isn't compatible with exposure to wide price changes. But there are also interesting cases where you want exposure to things like precious metals or stocks. It's a generic way to hold assets on the XRP Ledger that provide exposure to the price variability of other asset classes with minimal reliance on a counter-party. On the side of people who work on the XRP Ledger and want it to be awesome and able to solve real-world problems, all of these stablecoins are automatically liquid to XRP because of the redemption system. So if you make some asset liquid from XRP, it is liquid from every stablecoin. This really furthers the vision of XRP as a central liquidity pool for a variety of assets and payments. This is just a proposal. I like it a lot technically. It really feels to me like a beautiful system. But I'm not completely convinced that the benefits will outweigh the costs and risks. If you're one of those people who would love to see more on-ledger liquidity and more use of the on-ledger decentralized exchange, issued assets, or even community credit, I think this would be a huge step in that direction. Of course, someone has to actually use it for it to matter and it requires someone (or some coalition) to provide useful, reliable price feeds. A great next step would be for a few entities to step forward and express interest in operating stablecoins on the ledger.
  8. I may not have been consistent in my terminology. The operator creates the stablecoin, provides the price feed, and the trust line would be to their account. Anyone can issue the stablecoin by performing an issue operation on a position with sufficient collateral, but from the ledger's point of view, they're causing the issuer to issue the stablecoin to them. Though anyone can cause the stablecoin to issue, all the trustlines would be to the operator and all stablecoin balances in the same system are equivalent regardless of what position they came from.
  9. There are four ways you could wind up holding some of a stablecoin: You could create a trustline indicating that you are willing to hold the stablecoin and then someone could pay it to you. You could create a trustline indicating that you are willing to hold the stablecoin and then make a payment to yourself denominated in the same currency as the stablecoin. You could place an offer to acquire the stablecoin and then someone could take that offer. You do not need to create a trustline in this case. You could lock up some XRP and issue the stablecoin. You do not need to create a trustline in this case. Notice that in all four cases you have to do something to explicitly indicate your willingness to hold/accept the stablecoin. In two of the cases, it's creating a trust line.
  10. I made a video giving more details on the proposed design.
  11. It has several significant advantages over the DAI setup but one significant disadvantage. One key advantage it has over DAI is that any stablecoin issued by this system is guaranteed (assuming the system as a whole doesn't collapse) to be liquid to XRP at face value at all times the system operator has provided a current price. So you can safely use "niche" stablecoins pegged to a large number of different things such as stock or precious metal prices. Another advantage is that the only system fee is a fixed cost when XRP is locked as collateral. This can be set by the system operator and we expect it to be around 0.1% -- there are no fees that must be paid to redeem or close positions. The peg is held by the redemption and margin call logic, not by any attempts to control supply. The significant disadvantage it has is that a person who holds a position may be redeemed against because the token is liquid. So if you lock up XRP and issue a stablecoin, you may later find that some of your XRP was taken. Your position holds the same total value, but you lose leverage. This is done to the least-collateralized positions first, so you can reduce this risk by overcollateralizing. But avoiding losing leverage by having less leverage in the first place is not really a perfect solution.
  12. Thanks for responding. If the governance layer approves a list of validators for the inner layer, those validators agree on something, and that something complies with system rules, I don't see any problem with accepting that without waiting for the governance layer to specifically accept those ledgers or transactions. What would stop it from accepting them? Byzantine accountability can be handled with a delay. I'm not particularly worried about concurrent attacks on both the network topology and a significant number of validators because I don't think those kinds of attacks are realistic. The inner layer could temporarily censor. But if the outer layer is working, that wouldn't last very long. And if the outer layer isn't working, I'd rather have a temporarily censoring network than a temporarily stalled one.
  13. The advantage is that if you hold XRP directly, the value of what you hold changes over time. Some people want that, some people don't. This scheme lets those that want that hold XRP and those that don't can hold the stablecoin. Those that choose to hold the stablecoin have the equivalent of on-ledger XRP that is denominated in dollars, or whatever other peg they like. Someone creates a stablecoin pegged to some asset. The creator provides the price feed and governance. Then anyone who wants to can lock up XRP and issue the stablecoin. Holders of the stablecoin can redeem against the collateral. As the price changes, holders of the stablecoin have claims to changing amounts of XRP to keep the value of the stablecoin constant. Holders of XRP collateral have the value of the collateral change. Say you have $100 worth of XRP and you really want to be long XRP. With this scheme, you could lock that $100 worth of XRP up as collateral and issue $50 worth of a USD stablecoin. You could then trade that for XRP and have $150 worth of XRP locked up as collateral. You now have a leveraged long position in XRP.
  14. Light accounts would allow a limited account to be created without having to pay the 20 XRP reserve. Instead, a 5 XRP reserve would be paid. Light accounts would be limited in their function but they could certainly hold, receive, and send XRP. There are some options around what features a light account would be permitted to access. Light accounts could be permitted to have a single multisigner list or they could be permitted to have a small number of payment channels or escrows. Likely they would not be permitted to have any trust lines or offers. This post is one suggestion for an enhancement to the XRP Ledger. See this post for context: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  15. The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process. There is a judgment call involving what to permit an account to have and still be deleted. In principle, you could allow an account to be deleted regardless of what ledger objects it owned and clean up any problems after the fact. For example, if code later encountered an order, trust line, or escrow for a non-existent account, it would simply handle it appropriately at that time. Orders, for example, would be deleted when discovered to be orphaned. However, that’s probably not optimal. It’s probably sensible to require that some amount of cleanup be done prior to allowing an account to be deleted. In addition, all code that looks up accounts for trust lines, offers, escrows, and the like must be carefully audited to ensure it sanely handles a non-existent account. Due to the severe harm aberrant behavior could cause to those relying on the ledger, this audit is essential even if the implementation intent is that an account cannot be deleted while those objects exist. There is a standard draft for this suggestion: https://github.com/xrp-community/standards-drafts/issues/8 This post is one suggestion for an enhancement to the XRP Ledger. See this post for context: https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/ You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.