Jump to content


Ripple Employee
  • Content Count

  • Joined

  • Last visited

  • Days Won


JoelKatz last won the day on October 2 2019

JoelKatz had the most liked content!

About JoelKatz

  • Rank

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 gatew
  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 l
  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 i
  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
  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
  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 v
  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
  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 operat
  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 real
  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 agains
  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
  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 cod
  • 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.