Amendment Idea: Hosted Objects

[mvadari]

  title: Hosted Objects
  description: Allow any object to have a source tag indicating its (custodial) ownership
  created: 2025-09-17
  author: Mayukha Vadari 
  status: Idea
  category: Amendment

Hosted Objects

Abstract

Extending SourceTag/DestinationTag behavior of payments to object ownership as well

Better onboarding for users who don't want to manage their own keys - supports Coinbase-like usage of all features of the XRPL

1. Overview

We propose modifying the common fields of the ledger objects. No transactions will need to be modified, since SourceTag is already included in the common fields of all transactions.

This feature will require an amendment, tentatively titled ObjectSourceTag.

This amendment will essentially add a source tag to any object created in a transaction, if that transaction includes a SourceTag parameter.

2. On-Ledger Objects: Common Fields

2.1. Fields

As a reference, here are the fields that all ledger objects currently have:

Field Name	Constant?	Required?	Default Value	JSON Type	Internal Type	Description
LedgerIndex	Yes	Yes	N/A	string	Hash256	The unique ID of the ledger object.
LedgerEntryType	Yes	Yes	Object-specific	string	UInt16	The ledger object's type.
Flags	No	Yes	0	number	UInt16	A bit-map of boolean options enabled for this entry.

This spec proposes this additional field:

Field Name	Constant?	Required?	Default Value	JSON Type	Internal Type	Description
SourceTag	No	No	N/A	number	UInt32	Arbitrary integer used to identify the reason for the ownership of this object, or a holder on whose behalf this object is owned.

2.2. Conditions of Inclusion

• If there's a SourceTag on the creation transaction
• If there's a DestinationTag on the transfer transaction

3. Security

• Still need to trust that the service managing these objects is tracking everything correctly - #notyourkeysnotyourcrypto - but you can double-check on-chain
• IANAL - you probably need certain licenses to do this stuff since it's a custodial service

n+1. Open Questions

• DestinationTag should be added for every object that supports destinations (the only one where it's missing is NFTokenOffer)
• NFTs? Would mean a lot of extra space if it's per-NFT....
• Should it be called SourceTag or just something like Tag/OwnerTag?
• Maybe there's some nifty change in directory nodes that would make this easier to do

[xrpl365]

Interesting idea.
It does actually open the door for an entire new business model.
I'll leave the perceived value for others to determine but it's certainly a feature that could add value.

I'd steer clear of the term destinationTag and sourceTag tho, as these are known field names and I think it could cause confusion. I'd support one of your alternatives like ownerTag.

[dangell7]

Would this spec replace the spec on sub accounts? #283

[mvadari]

Not really - accounts can't own other accounts, and you can't split up balances between many source tags with this solution.

[dangell7]

I feel like this might create confusion later if both were implemented though. If sub accounts can hold sub objects and regular accounts can hold "sub objects" then we have 2 implementations doing the same thing.

Is there a clear difference here? Easier to implement this spec? Is there a way we could make this transition into sub accounts?Which feature is Coinbase/Enterprise specifically asking for? balances and sub account control or just sub objects?

[mvadari]

That's fair.

Nobody is asking for this AFAIK, it's an idea that came out of a casual conversation more than a year ago that I happened to write down. I'm just posting all my ideas in case someone else finds some utility out of it/wants to run with it (it's happened before).

Context: https://x.com/msvadari/status/1966223730780344337?t=MEyZ0K1giRiNnP2JpoZG3w&s=19