Jump to content


Bronze Member
  • Posts

  • Joined

  • Last visited


About King34Maine

Recent Profile Visitors

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

King34Maine's Achievements

  2. I think he may be referring to Stellar's Franklin Templeton partnership/MOU a couple years back. However, the extent of the partnership was just to have FT's new fund transaction records be recorded on the the Stellar blockchain. Not that FT was tokenizing any securities via Stellar. Not sure what has come of the partnership to date.
  3. BTW, I have your most recent blog post, "KYC Compliant Trading Using GlobaliD and the XRPL DEX" on my bucket list to read.
  4. I don't necessarily feel like they're being reactive, but trying to find the right product/market fit for NFTs. I think Ripple realizes that they can't stand idle while other platforms are experimenting with new blockchain uses cases and products. This is one of the primary reasons RippleX was created besides being a gateway/resource for the XRPL community developers. Ripple's core raison d'etre is still intact around all things payments/value etc., however, RippleX allows them to take risks with new concepts and ideas. To me, I feel Ripple has been very deliberate and strategic in how they approach some of these new use cases so as not to get caught up in all of the preliminary hype that typically surrounds them at the onset. There's a pretty good discussion related to NFTs via the XRPLF's Standards Github portal on Non-Fungible Token Support. Forte's Engineering Leadership posted a wish list of features/functionality they are partnering with RippleX to developed for NFT support on the XRPL. Here's the Forte Engineering Leadership post: "Thanks XRPL team for putting together this comprehensive spec. From our perspective at Forte, the design is thoughtful and would cover many important use cases we have come across with our game developers. We are excited to see it go live! Below I have included a descriptive wishlist from our perspective, that would help make for serving game developers and their deep use in the NFT space. It has a fair amount of crossover with the above insights and comments from the rest of the community, particularly around the transfer fees design and metadata commentary. I have included the bulk of our feedback to do justice to the team's thinking, so apologies for the long windedness. Thanks ahead for enduring Quick takes: This seems like an efficient, stateless NFT design. Structuring NFT management/organization at the user/account/owner level will reduce tracking complexity, which is great. We really like the idea of offers on-ledger, and the idea of a specified take rate on-ledger for the original issuer of an NFT. These are differentiated features and we think they will add value in the ecosystem. More below. This design would cover some of our known use cases, but has some limitations around asset use cases which are useful in games. In particular, we think this design is workable for totally unique, singleton assets. Classic “NFTs”. Adding a stateful field for provenance history verification may be worthy of consideration. See more detailed notes on this below. The design could be used for Semi-fungible tokens per the Further Development section, but some potential snags could exist without some kind of distinct object types and/or modifying the NFT Offer system to allow for both unique/non-fungible tokens and semi-fungible tokens Wish list: (1) Provence Tracking: This proposal works well for totally unique items. At the same time, it doesn’t provide everything one might hope for with respect to totally unique assets. In particular, provenance/ownership history would have to be tracked and verified entirely off-ledger. Of course, provenance and chain of custody can be tracked and verified off-ledger by walking all transactions where a given NFT was transferred. However, doing so would be expensive both to prove and to verify. It may be worthwhile to add a stateful field, updated each time an NFT Object is transferred to a new owner, which could be used as a witness to at least quickly verify off-ledger claims of provenance and custody history. For example, perhaps a custody chain hash field is introduced, such that on creation: ProvenanceHash = hash(issuer), and on transfer: ProvenanceHash = hash(ProvenanceHash, newOwner) With this system, a claim about the chain of ownership could be made off-ledger, and anyone could quickly verify it’s veracity by looking at this proposed field for the NFT object on-ledger and computing the hash sequence of each owner in the purported ownership history chain. Our wishlist proposal here only works for truly unique/non-fungible assets. See our thoughts below regarding semi-fungible assets. Wish list: (2) Issuer-based queries for NFTPages: The NFTPage system will be extremely helpful in reducing the complexity for application developers when trying to find all the NFTs a single user owns. However, in the context of videogames, it is not uncommon for a single game to issue 100-1000’s of items to a single player. When you expand this concept for a user who plays multiple games, this may result in a lot of pages. If so, filtering the NFTPages to select the NFTs which are usable in your application may be expensive. We don’t have a specific solution proposal for this. However, at scale a game application is often the Issuer of the NFTs for the game, perhaps grouping NFTPages by Issuer could make sense, or if implementing an Issuer-based index or query system for NFTPages would be worthwhile. The goal being that a single application can quickly determine which of the NFTs a user owns can be used in their application without having to walk all the pages, but may be too specialized for many other use cases. Comment: (3) Semi-fungible tokens Because non-fungible and semi-fungible tokens have very different semantics, we wonder if it is worth supporting a distinct SFTObject (now or later). Wish list: (4) Transfer Rates: We really like the idea of having an on-ledger field in NFT objects for TransferRate. Even though royalty shares can’t be enforced for off-ledger payments, a designated on-ledger TransferRate could be an important social coordination signal. Enforcing the TransferRate for on-ledger payments may also help normalize the idea that payments should happen on-ledger, and provide a good justification for encouraging the ecosystem supporting NFTs on XRP Ledger structure payments this way. For example, this may encourage more marketplaces that support XRPL NFTs to use on-ledger transactions (and XRP) for all payments. We wonder if it might be worthwhile to modify the Issuer and TransferRate fields such that they form lists. Obviously application developers and other platforms can manage these royalty distributions on their own, off-ledger. But support for multi-party issuance and according transaction revenue splits may be a worthwhile enhancement of the proposal. (mentioned in other user comments as well) Wishlist: (5) Multisig NFT transfers: The current design indicates that an NFTOffer can be fulfilled by agreement between the owner and the receiver of the offer. Would it be possible to add support for a multisig offer where the “Issuer” additionally has to approve the trade as well? Perhaps this could be accomplished with an additional field in the NFT object, specified by the issuer at issuance. Alternatively, could an issuer require that an NFT they issue can only be held in a multisig account to which the Issuer is a party, with a required key? For compliance with BSA/Money Transmittal/AML regulations, it may be useful for some issuers to require their explicit approval of transfers of NFTs. Forte implements a system like this for certain asset exchanges involving tokens defined on EVM-compatible blockchains. Obviously, this idea detracts from self-sovereign property rights, including the right to transfer assets at will, but it may be necessary for some issuers to ensure they can enforce compliant exchanges of valuable assets if they issue those assets. Supporting multisig authorization for any NFT transfer may encourage a broader market with more assets created by more issuers."
  5. There's plans to integrate the XRPL into Mintable's NFT platform. RippleX participated in Mintable's Series A funding round. From the RippleX article I beleive the XRPL's DEX will be utilized here: "The XRP Ledger (XRPL)—with its innate performance advantages and built-in decentralized exchange (DEX)—is ideally suited to deliver a seamless experience for NFTs. In order to reach the next stage of growth, Mintable plans to integrate with the XRPL so creators can securely, sustainably and efficiently sell their works. This is also true for users who wish to purchase NFTs and resell them. The Federated Consensus algorithm - core to the design of XRPL - ensures low-cost transactions and positive implications for sustainability. By being able to cut transaction (“gas”) fees down to $0.0004 on XRPL, Mintable recognizes the opportunity to offer a differentiated user experience that provides a competitive advantage in comparison to other marketplaces. In fact, the XRPL consumes only about 790,000 KWh per year and is already carbon neutral, which is far more efficient than proof-of-work networks that consume around 66 TWh of energy per year. In a nutshell, its environmentally friendly attributes will allow billions of NFTs to be minted, bought and transferred on the XRPL in a sustainable way."
  6. I agree. Unlike with the Private XRPL CBDC ledgers, Ripple cannot unilaterally add new features, like the Federated Side-chains, to the XRPL since such a feature will require a 80% or better vote from validators on the XRPL. David's post is Ripple's way of soliciting input from the XRPL community. Kinda like how Ripple dropped the news back in March that they had been working with CBs on utilizing a private version of the XRPL for CBDCs. Large scale projects like that takes years of planning, preparation, and testing. This is why I feel real confident that this Federated Side-chain Feature is a key component in the Private XRPL CBDC Ledgers and has already been tested throughly by Ripple and potentially CBs.
  7. Being able to abstract burdensome features away from the XRPL to prevent congestion/high fees on the main net like we've seen run-a-muck of the Ethereum platform makes plenty sense in my opinion. Reading David Schwartz's vision for Federated side-chain made it seem as if they are just now exploring this new feature. However, I suspect that Ripple already has a fully operational federated side-chain version built and ready to go for its Private XRPL Ledgers for CBDCs. I expect they will copy and paste a good portion to utilize for the XRPL main net.
  8. Yes, crypto can be very strange at times. Wondering what's your take on El Salvador possibly accepting Bitcoin as legal tender? I can almost imagine that this most likely didn't have the blessings of the IMF/BIS. Not that it has to, but I'm quite sure this development wouldn't sit well with them given that the IMF/BIS most likely coordinated the efforts in transitioning El Salvador from its failed currency (Colon) to the USD back in 2001.
  9. Not yet, but with Hooks it will as I stated in my initial response.
  10. It could very well have been some malware on the phone you used to login to your Coinbase account. There are some very sophisticated spoofing malware out there. Had this one happen to me a year ago: https://iwantleverage.com/security/phishing-attacks-are-more-cunning-than-ever/
  11. Within the RippleX community of developers XRPL Labs is working on native/XRPL-based smart contract functionality via an amendment called "Hooks." Flare Networks is a touring-complete Federated Byzantine Agreement (FBA) smart contract platform. The first Hooked article below explains/details the difference between native smart contract functionality (Hooks) vs Flare Networks (touring-complete). Hooked #1: Smart Contracts on the XRP ledger Hooked #2: Hooks & Security (Smart Contracts on the XRP ledger) Hooked #3: Tech Preview Release (Play with Smart Contracts on the XRP ledger!) Hooked #4: Every Microsecond Counts Hooked #5: Consensus Hooks GitHub Ripple also has Codius which was developed way back in 2015 by Ripple's former CTO, Stefan Thomas (now CEO of Coil and Chairman of the Interledger Foundation). It has been pretty much in stealth-mode since then. In the Codius link I referenced, Stefan goes into the reason(s) Codius has yet to be fully realized. Recently, Stefan added a bit more color to picture on Twitter about how he and Evan Schwartz (Coil Board member and President of the Interledger Foundation) worked on Interledger and Web Monetization to provide the infrastructure that will help facilitate more rapid up-take of Codius (worth a read). On a recent podcast Ripple's current CTO & co-creator of the XRPL, David Schwartz, further elaborates as to the reason(s) Codius has yet to be implemented and his thoughts on Flare Networks.
  12. I'm quite sure you can explain your situation (i.e. needs, expectations, time-line, benefits, costs, etc.) with representatives from Ripple's Sales/Customer Success division via the link provided above. They can forward you information regarding the platform to see if you think that your organization would benefit from RippleNet. Case Studies/Content Library: https://ripple.com/customer-case-study https://ripple.com/content-library/ Quick Guide To RippleNet: https://ripple.com/wp-content/uploads/2019/12/RippleNet-Quick-Guide-Overview.pdf Note that when researching about the various solutions offered by Ripple you will come across: xCurrent, xVia, and xRapid (now ODL - uses XRP). These were three separate products offered by Ripple until they combined them into a singular platform (i.e. RippleNet). Here's an old Cost Cutting Guide that Ripple put together for banks back in 2016. I'm quite sure a lot has changed since then, but it will give you an idea of the cost/benefits of using RippleNet and/or ODL (formerly known as xRapid): https://ripple.com/files/xrp_cost_model_paper.pdf Ripple's most recent product: https://ripple.com/insights/fund-instant-cross-border-payments-with-a-line-of-credit-from-ripplenet/
  13. Damn bro.....you came back with a vengeance with all of the XRP/Ripple related information....Thanks!!!
  • 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.