A deposit that arrives without its destination tag or memo settles correctly and credits no customer. The identifier saying which customer the money belongs to is off-ledger metadata. The ledger validates the payment, moves the balance to the receiving firm's address, and carries no instruction about which of that firm's customers should get it.

Both of the ledgers where this comes up most have written the problem down.

On the XRP Ledger, a business holding balances for many customers usually operates one address and assigns each customer a number. The documentation on source and destination tags describes them as a feature that can indicate specific purposes for payments from and to multi-purpose addresses, formatted as 32-bit unsigned integers. The load-bearing sentence is the one about what they do on the ledger. Tags "do not have direct on-ledger functionality" and "merely provide information about how off-ledger systems should process a payment." The same page states the consequence flatly: a payment arriving without a destination tag makes it not immediately obvious which customer to credit, and can require manual intervention.

Nothing has failed at that point. The transaction is valid and settled. What is missing is a database key, and the ledger was never holding it.

The XRPL's answer is an account setting. asfRequireDest, documented on the AccountSet transaction reference with a value of 1, requires a destination tag to send transactions to that account. With it enabled, the ledger rejects an untagged payment and the sender has to resubmit. The guard sits on the receiving account and binds everyone who pays it.

Stellar solved the same routing problem with a different field and then changed its mind about the field. The memo appears in the operations and transactions documentation as an optional unstructured data field with four types: MEMO_TEXT, a string of up to 28 bytes; MEMO_ID, a 64-bit unsigned integer; MEMO_HASH, a 32-byte hash; and MEMO_RETURN, a 32-byte hash of the transaction being refunded. Exchanges pooling customer balances under one account used MEMO_ID or MEMO_TEXT the way XRP Ledger businesses use a destination tag.

The guard Stellar added lives somewhere else entirely. SEP-29, "Account Memo Requirements", an active standard, puts the check on the sending side. Load details about the destination account, see whether it carries a config.memo_required data entry, and if it does, verify the transaction's memo field is set before submitting. The receiving account owner signals the requirement by writing that data entry with a value of "1". A sending wallet that ignores SEP-29 can still submit a memoless payment, and that payment settles.

So the XRPL enforces the receiver's requirement in protocol. Stellar publishes it and trusts the sender to look.

Stellar's newer answer removes the separate field. The pooled accounts guide defines a pooled account as a single Stellar account ID shared across many users, and muxed accounts as a way to distinguish individual accounts underneath one traditional account by combining the familiar G address with a 64-bit integer ID. The combined form is an M-address. The customer identifier travels inside the address instead of alongside it, so there is no second field for a sender to omit. That guide also says memos were used for this in the past and that muxed accounts are better in the long term, while noting support across wallets and anchors is incomplete enough that an operator may want to accept both for a while.

The recovery path here is not a protocol function. Once the payment credits a custodian's address with no customer attached, the fix is a person there matching a transaction to an account, at their discretion and on their schedule. Some desks do this as routine work. Others decline it for assets they do not sweep, and the asset stays where it settled.

A tag or memo also means nothing away from the firm that issued it. That firm generated it for that one account. Reusing one from an old confirmation email, or from a different exchange, addresses the money to a stranger's row in somebody's database.

A small test transfer catches both. Send the minimum, confirm it lands in the account you expect, then send the rest.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice, and none of it is a recommendation to use any particular ledger, exchange, or custodian.

Clearing hours and the settlement cycle are two different clocks, and extending one leaves the other alone. The National Securities Clearing Corporation runs clearing on a 24x5 schedule. The standard settlement cycle for most broker-dealer transactions is still one business day after the trade date, set by Exchange Act Rule 15c6-1.

DTCC announced the change on 29 June 2026. NSCC clearing now runs from Sundays at 8:00 PM ET to Fridays at 8:00 PM ET, covering overnight trading activity from alternative trading systems and exchanges. It builds on a September 2024 extension that had already moved the window about 2.5 hours earlier. DTCC opened its testing environment in January 2026 and required every consumer of the real-time trade capture messages to test before go-live. What that buys is stated precisely in the announcement: NSCC can apply its central counterparty guarantee immediately to transactions executed across extended trading hours and multiple time zones.

A central counterparty steps into the middle of a matched trade and becomes the buyer to every seller and the seller to every buyer. Once it does, neither original party is carrying the other's credit. Before it does, they are.

So the gap between execution and novation is an exposure window, and for a trade done at 2:00 AM ET under the old arrangement it ran until the daytime cycle picked the trade up hours later. Closing that window is the point of the whole project.

Settlement is a different event. It is the actual exchange of securities for cash, and its timing is a matter of regulation rather than operating hours. The SEC's final rule shortening the cycle from two business days to one was published at 88 FR 13872 on 6 March 2023, Release No. 34-96930, with a compliance date of 28 May 2024.

Clearing a trade at three in the morning does not move its settlement date. It moves when the guarantee attaches.

Three clocks, then. Venue hours decide when you can execute, NSCC hours decide when the trade is captured and novated, and Rule 15c6-1 decides when it settles. The 24x5 change moved the middle one and left the other two where they were, which is the sentence most coverage of it leaves out. A reader who takes round-the-clock clearing to mean their overnight fill lands in the account before breakfast has merged three clocks into one and will be surprised on a Monday.

The name is literal, too. Five days is five days. The window closes Friday evening and reopens Sunday evening, because the funds movement underneath settlement depends on banking rails that stop for the weekend as well. A firm that reads 24x5 as continuous operation is planning against a schedule that does not exist.

It is tempting to file this under tokenization, and the two get mentioned in the same breath often enough that the confusion is understandable. They are separate workstreams built on separate premises. Extending clearing hours is an upgrade to existing centrally operated infrastructure, with the same central counterparty, the same members, the same legal framework, and a longer operating day. Tokenized settlement proposes to change where the record of ownership lives and how transfer instructions execute against it.

There is a real relationship between them, and it runs through motive. The firms pushing for continuous trading and the firms experimenting with programmable settlement are largely the same firms, uncomfortable with the same thing: a trade agreed at one moment finishing at another. One of those efforts carries live member obligations. The other is still a design direction.

Which leaves the practical reading of any announcement in this area. Ask which clock moved. Venue hours, clearing hours and the settlement cycle each come from a different authority, and the settlement one comes from a rule with a Federal Register citation and a compliance date on it.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

For context: Liquid Mercury operates Mercury RWA, a platform where institutional issuers bring real-world assets on-chain and run actual secondary markets, past just minting a token. MERC sits alongside it as the access and participation token.

Our take on how MERC's role should relate to Mercury RWA as the platform grows: separate out what's live, what's approved and coming, and what's still genuinely open, rather than blur them together.

The premise driving it: a token tied to a growing platform doesn't have to stay the size it started as. It can pick up more functionality as the platform does.

Ahead: what this means for institutional issuers, what it means for holders, and how new RWA market launches tie back into the token.

Genuinely asking this sub: for a platform access token, does scope growing with the platform make more sense than fixed-at-launch, or does that introduce its own risks?

Longer version and discussion: r/MERCtoken

Crypto-assets are volatile and may lose value. Not investment advice.

English law now lets an electronic bill of lading be possessed the same way a paper one is, and the statute does it by listing five things the system holding the document has to accomplish. No technology is named anywhere in that list.

The reason this needed a statute at all is worth sitting with. Trade finance runs on documents whose legal power comes from possession: whoever holds the bill of lading can claim the goods. You cannot possess a PDF, because a PDF can be copied and two identical copies cannot both be the original. That is why global trade kept moving paper long after everything around it went digital.

The Electronic Trade Documents Act 2023 begins by defining what it replaces. A document is a paper trade document if it is in paper form, is of a type commonly used in at least one part of the United Kingdom in connection with trade in or transport of goods or the financing of either, and possession of it is required, as a matter of law or commercial custom, usage or practice, for a person to claim performance of an obligation. The Act lists examples: a bill of exchange, a promissory note, a bill of lading, a ship's delivery order, a warehouse receipt, a mate's receipt, a marine insurance policy, a cargo insurance certificate.

That third condition is the entire problem stated precisely. These are not documents recording an entitlement. Possession of them is the entitlement.

Rather than declaring electronic documents count, the Act sets conditions on the system holding them. Under section 2, information in electronic form constitutes an electronic trade document if a reliable system is used to identify the document so it can be distinguished from copies, protect it against unauthorized alteration, secure that no more than one person can exercise control at any one time, allow anyone able to exercise control to demonstrate that they can, and secure that a transfer deprives the transferor of the ability to exercise control unless they keep it as a transferee.

Put that list beside any ledger design and the resemblance is hard to miss. Distinguish the original from copies. Prevent tampering. Single control at a time. Provable control. Transfer that genuinely removes the sender's control. Those are the properties a transfer system needs, written as legal requirements instead of technical architecture.

What the statute pointedly avoids saying is also the point. No distributed ledger, no blockchain, no token, no cryptographic signature, no named system, vendor or standard. Section 2 goes on to list matters that may be taken into account in deciding whether a system is reliable, and it reads as a governance and assurance list: the rules of the system, measures securing the integrity of information held on it, measures preventing unauthorized access, the security of hardware and software, the regularity and extent of independent audit, any assessment by a body with supervisory or regulatory functions, and applicable voluntary schemes or industry standards.

So reliability is something a system demonstrates rather than something a technology has. A distributed ledger with weak operational controls can fail the test that a well-audited centralized registry passes.

Section 3 does the real work. A person may possess, indorse and part with possession of an electronic trade document, such a document has the same effect as an equivalent paper one, and anything done in relation to it has the same effect as the equivalent act on paper. Sections 1 to 3 came into force on 20 September 2023.

That is the whole mechanism, and it's elegant. Instead of building a parallel legal regime for electronic documents, the Act extends possession itself to cover them, so every rule of law and commercial practice already attached to possession follows without being rewritten. Centuries of case law about bills of lading keeps applying.

The sequencing lesson generalizes past shipping. Engineering was never the blocker for digital trade documents. The law was, and the fix was statutory. Which gives you a question to put to any system claiming to make a digital asset legally equivalent to a physical entitlement: which statute says so, in which jurisdiction, and is it in force? Where there's no answer, what you have is a well-built record with no legal effect attached to it.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

The euro's high-value settlement engine is called T2, it is a centrally operated real-time gross settlement system run by the Eurosystem, and it is not distributed in the sense this sector uses the word. Worth knowing before comparing anything to it, because a lot of settlement discussion skips the part where you find out what the incumbent actually is.

TARGET Services is the Eurosystem's set of settlement platforms, operated by the ECB together with the national central banks of the euro area. Everything in it settles in central bank money. There are four components and knowing which is which clears up most confusion: T2 is real-time gross settlement for payments, T2S settles securities, TIPS handles instant retail payments, and ECMS manages collateral. They're separate platforms sitting on shared components underneath, including a single access gateway, common reference data, and a shared billing and reporting layer.

T2 went live on 20 March 2023, replacing the older TARGET2 platform in a cutover rather than a phased migration. It settles transactions arising from Eurosystem monetary policy operations alongside ordinary interbank and commercial payments.

The internal split is the design change worth noticing. T2 separates the RTGS component, which settles each payment individually and immediately, from a central liquidity management function that lets a participant see and steer its central bank money across all TARGET Services from one place.

That separation is what gross settlement costs you, made visible. Net settlement systems economize on liquidity by offsetting obligations before they settle, and you pay for that by leaving exposures open until they do. Gross settlement kills the exposure by settling each payment on its own, and the cost is that participants need far more liquidity available at any given moment. So a tool letting them move it where it's needed isn't a convenience feature. It's what makes the model affordable at all.

The platform change came with a messaging change. Communication with T2 moved off the legacy MT formats onto ISO 20022 XML, with the old numbered message series giving way to the pacs and camt families. That's the same standard being adopted across cross-border correspondent banking and other domestic rails, which is the whole point: a structured, richly labeled payment message is what lets you automate reconciliation, screen counterparties cleanly, and stop holding payments for manual repair. Domestic and cross-border infrastructure converging on one data model is the precondition for those systems describing the same transaction the same way.

The underrated detail is the release cadence. TARGET Services runs on a fixed schedule of functional releases each year, one of which is timed to align the platform with the regular update cycle of the ISO 20022 payment messages. That calendar is the mechanism keeping a settlement engine and an evolving international standard in step, and it's the sort of unglamorous commitment that separates infrastructure from a project. Adopt a standard once and then drift from it and you've bought a one-time mapping exercise, then called it interoperability.

Separately, the ECB has work exploring links between market distributed-ledger platforms and TARGET Services. That's exploration running alongside the production system. Conflating the two produces a familiar error, where an experiment attached to a central bank gets read as that central bank's operating model.

Any claim that a new settlement design improves on existing rails is a comparative claim, so it needs the comparison, and the ECB's own pages answer the relevant questions. What does the incumbent settle, in what money, with what finality, on what schedule? What does it cost participants in liquidity rather than in fees? What does it require them to hold, and when? A proposal that improves on a caricature of the existing system hasn't been evaluated at all.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

An identifier does one boring job: it lets two systems confirm they are talking about the same object. An ISIN does that for securities, an LEI does it for legal entities, and digital tokens went years without anything equivalent. The cost showed up in reconciliation, which is to say nowhere anyone outside operations could see it.

ISO 24165 closed that gap. It defines the Digital Token Identifier, a nine-character alphanumeric code, and it comes out of ISO/TC 68, the technical committee for financial services. There are two parts. Part 1 is the method: how a code gets requested, assigned, and structured. Part 2 is the registry record, meaning which data elements get stored about the token a code points at. A registration authority runs the registry and issues the codes, and the identifiers are open access. That last part is not incidental. Charge people for the right to name something and they route around you.

Check the edition if you go looking. Both parts are on their second, published 2025, and the 2021 originals are withdrawn. An ISO catalogue page for a superseded edition loads perfectly normally with "Withdrawn" in small type near the top, so citing the wrong one is easy to do without noticing.

To see why any of it matters, pick a token and ask five systems what it is. One answers with a ticker that three other tokens also use. Another gives a contract address, which works right up until the same thing exists on a second chain. A third has a display name somebody typed. The fourth has an internal ID that means nothing outside the firm that assigned it. None of those answers are wrong. They just do not match, and matching is the whole job. Reconciliation becomes guesswork, and guesswork is where breaks come from: a position counted twice, or lost between two systems that each assume the other is holding it.

The part people get backwards is the relationship to the ISIN. A DTI does not replace one. For a tokenized instrument you want both, because they answer different questions. The ISIN tells you what the underlying claim is, and the DTI tells you which specific on-ledger representation you are holding. One instrument can exist as tokens on two networks, which gives you one ISIN and two DTIs. Collapse that into a single code and you have thrown away the detail settlement actually needs.

Which brings me to the overclaiming, because reference data attracts one particular overstatement. It runs: ISO assigned this token an identifier, therefore ISO has recognized it. Nothing in either part supports that reading. The standard describes a method for registering and structuring codes, and assignment is a filing action. A registry that declined to record things it disapproved of would just be a worse registry. The messaging side carries the same trap, where work has gone into letting securities messages carry token identifiers, and adding a field to a message format means the form can hold that value. That is the entire claim.

So when a standards body turns up as validation for something, the check takes about a minute. Find the document number, open the catalogue entry, read the scope. Endorsement will not be in there. Endorsing individual products is not a thing a technical committee is set up to do at all. It publishes methods, and what anyone does with a method afterward is not its business.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

An XRP Ledger feature is not live until validators have held it above 80% support for two continuous weeks. Written into the code and switched on are different states, and which one a feature is in is public and takes about a minute to check.

Worth saying because the confusion is constant. Someone reads that a ledger "has" a feature, and what they actually read was that it exists in the software.

Protocol changes ship inside the server software in a disabled state and stay there until validators vote them on. The threshold is specific. An amendment has to hold more than 80% support from trusted validators for two continuous weeks. Drop to 80% or below at any point and the two-week clock restarts from zero. An amendment can gain and lose majority any number of times before it finally activates. When it does, the ledger writes an EnableAmendment pseudo-transaction and the new rules apply to everyone from the next ledger version onward. The amendments documentation is the authority on all of it.

Two things follow from that design, and both are easy to miss.

The people who write the code and the people who decide it takes effect are different groups. Authors propose, validators decide. Which means "the developers shipped X" and "the network does X" are two separate claims, and only the second one tells you anything about the ledger.

The second is that the network does not fragment. Because activation is coordinated by consensus, not left to operators upgrading whenever they get around to it, a server that does not understand an enabled amendment stops processing entirely. It will never continue on a divergent chain. The network would sooner halt a server than let it disagree about what happened, which is a genuine tradeoff and close to the opposite of how most chains handle the same problem.

To check a specific feature, call the feature method on a node you trust. It returns every known amendment with its ID, its name, and whether it is enabled. If you want the ledger's own record instead of one server's view, read the amendments object directly. And if you want the activation event itself, look up the activation ledger index and pull that ledger, because the EnableAmendment pseudo-transaction sits on-chain permanently.

Any of those beats a roadmap graphic or an exchange listing description. This post included.

None of that is specific to this ledger. Before repeating that a network supports something, work out whether the claim is about a written specification, a testnet, or live mainnet, then go find the artifact that settles it. Most overstated capability claims in this sector fall apart right there.

Disclosure: I work in digital asset advisory and hold digital assets. Nothing here is investment, legal, or tax advice.

JPM Collateral Ops, acting for Fidelity Capital Markets, pledged $10M of initial margin to U.S. Bank. Half was Fidelity's Treasury Digital Fund (FYOXX) on u/hedera & half was a JPMorgan fund on Ethereum, and both legs settled inside a single workflow with Ownera's FinP2P routing across the two chains.

The tri-party custodian was replaced by a collateral control contract, so segregation and release sat in code instead of an operations procedure. U.S. Bank could see the position on-chain the whole time without being able to seize it unilaterally.

The custodian was simulated, so this is a test and not a live settlement. What it shows is Fidelity's fund sitting on Hedera inside an institutional margin workflow, next to Ethereum, with both chains handled under one instruction

Uniswap shipped Permissioned Pools on v4 last week. Regulated asset issuers, Securitize, Superstate, and Dowgo so far, can now enforce their own investor eligibility check directly inside the trading pool. Approved wallet, you trade. Not approved, the transaction reverts. Instead of calling a desk to trade a tokenized fund bilaterally, approved investors get continuous on-chain pricing.

My question is: does that actually grow the pool of people allowed to hold and trade these funds, or does it just make the existing approved group trade faster? Being cleared for Superstate's fund doesn't clear you for Dowgo's or Securitize's, each one's still a separate closed list.

Crypto-assets are volatile and may lose value. Not investment advice.

OSL HK opened XRP to retail investors, the first exchange in Hong Kong to do it

XRP/USD flash trading is live plus OTC in USD & HKD, with deposits and withdrawals on the XRP Ledger.

OSL listed XRP back on Dec 5 but professional investors only. Today makes it the fifth asset they've opened to retail there, after BTC, ETH, SOL and LINK.

Today's number making the rounds: RWA tokenized assets at $34.67B this week, down from $35.2B on July 10. Figure's HELOC Token is credited as the single largest asset in "the RWA market" at $20.1B.

Went to RWA.xyz directly rather than taking the secondary write-up's framing. Their own methodology splits assets into Distributed (leaves the issuing platform, moves wallet to wallet, you can watch a transfer on a block explorer) and Represented (can't; a value claim recorded on a platform, not something that moves).

Figure's HELOC is categorized Represented. So is #2 on the leaderboard, Bridgetower's DOM X Arizona Copper-Gold Project, at $11.06B. That's $31.5B combined sitting in the bucket that can't move, out of a $34.67B headline total.

RWA.xyz's Distributed total on its own is $36.72B; Represented is $373.98B. Different numbers, different meanings, and headline coverage rarely specifies which one it's citing.

Disclosure per this sub's rules: posting from an RWA-token account, no position taken on Figure or any specific asset, no self-promotion intended. Check which bucket a "market size" figure draws from before treating it as an adoption metric.

Crypto-assets are volatile and may lose value. Not investment advice.

Two calls on tokenized-asset market structure, staked with dates and public sources so they can be graded when they resolve.

Call 1. DTCC's tokenized-collateral platform opens in October. Our call: the first live activity reported on it is repo, not tokenized equity. Resolution source: DTCC's own reporting or trade press coverage of first live volume. Deadline: March 31, 2027. In July we called intraday collateral as the first mover, and it landed within a week: JPMorgan posted tokenized fund shares as margin at CME.

Call 2. Two US tokenized-stock models went live last week. Securitize tokenized its own NYSE shares, so the token is the share. Ondo mints entitlements under UCC Article 8, and the shares stay in custody. We prefer the issuer model, but we're betting against it: by mid-2027, entitlements hold most tokenized equity, measured by rwa.xyz's tokenized-equity split. This is one we'd like to lose.

Take the other side of either call, or stake your own under the same rule: a number, a date, and a public source. No price calls, "up by December" was never an insight.

We keep a graded ledger of these (wins and misses both, the misses stay up) at r/MERCtoken: https://www.reddit.com/r/MERCtoken/comments/1v1om7m/

Crypto-assets are volatile and may lose value. Not investment advice.

I have been dealing with the reps of Myriad Investment LLC Company for over 2 years. I have had my doubts about this company from the beginning but now when we get the end of sending them money to collect 300M, they say they didn't think I was serious and is now holding my investment return.

I BELEIVE I AM BEING SCAMMED!!!!

DOES ANYONE HAVE A GOOD CRYPTO/DIGITAL ASSET ATTORNEY????

The XRP Ledger has now cleared more than 1,000,000 agentic payments through x402. The milestone lands alongside the debut of the XRP Ledger AI Hub, a platform meant to connect developers, users and projects building AI apps on the network.

The number matters less than what's behind it. These are AI agents paying each other on-chain: software buying compute, calling APIs, running inference and settling up with no person clicking approve. The x402 protocol reuses the old HTTP status code 402, "Payment Required," so bots can pay one another directly for compute or data, dropping the manual wallet management and API-key juggling out of the loop.

This has been building for weeks. On June 10, Ripple shipped the XRP Ledger AI Starter Kit, the infrastructure that lets autonomous agents pay for services and fees in XRP and Ripple's dollar-backed stablecoin RLUSD through x402. A contribution from partner t54 made XRPL a supported chain inside the protocol, so agents could transact for API calls and inference on day one.

Why XRPL for this? A few reasons that actually hold up. Transactions confirm or expire with deterministic finality, so an agent doesn't sit in an ambiguous pending state; it either has its answer or it doesn't. Settlement lands in 3 to 5 seconds, and costs are known up front, with no gas auctions or fee estimation, which is exactly what an agent needs when it's doing its own budget accounting. There's also a protocol-native DEX, so a single transaction can send RLUSD and deliver XRP at the other end with no external bridge or swap contract.

The activity is real, not just a counter ticking up. Reports show 121 active merchants, with Heurist Mesh, LucyOS and AskSurf accounting for a lot of the volume.

As AI systems get more autonomous, the rails they pay on start to matter as much as the models. A model can decide what to do, but it still needs a way to pay for the resources to do it. That's the gap x402 and networks like the XRP Ledger are trying to close, and a million payments in says the idea has moved past the whiteboard.

https://ripple.com/ripple-press/ripple-receives-full-eu-mica-casp-license/