Jump to content

JoelKatz

Ripple Employee
  • Content Count

    882
  • Joined

  • Last visited

  • Days Won

    82

JoelKatz last won the day on October 2

JoelKatz had the most liked content!

About JoelKatz

  • Rank
    Advanced

Contact Methods

  • Website URL
    https://gigabitether.net

Profile Information

  • Gender
    Male
  • Location
    Oakland, CA
  • Occupation
    Chief Cryptographer, Ripple
  • Ripple Address
    ~JoelKatz

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. I made a video giving more details on the proposed design.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. Most public ledgers provide no way to refuse an unwanted incoming payment. While most people would be perfectly happy to receive an unexpected, possibly misdirected, payment, it can create a real problem for some users. Regulatory requirements may make returning the payment difficult but they may also make keeping the payment difficult. We propose adding a feature to allow recipients to actively accept payments. We dubbed the feature “checks” internally. A sender can, instead of making a payment, create a check payable to a recipient. The recipient would have to actively claim the check. Users who do not want to receive unrequested payments could set their account to only accept checks. They could then simply not accept any unwanted payments. A whitelist of accounts permitted to send directly could be offered. Checks can also be used if the sender is not positive that the receiver still has access to the account. If the check is not cashed within some time period, the sender can cancel it and ensure the funds do not leave their account in the future. 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. Some enhancements could be made to the XRP Ledger to provide better support for emerging use cases in decentralized finance. For example, validations could be augmented to include the last fully-validated ledger. This would permit validators to automatically operate as oracles and allow, for example, users to prove to Ethereum smart contracts that particular things happened on the XRP Ledger. 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...