Supporting Contract Accounts in Funding New G-Accounts

[marcelosalloum]

Challenge

Currently, Contract Accounts cannot fund the creation of G-accounts, unlike Classic G-accounts, which can create and fund other G-accounts using the create_account operation.

Account creation requires a triggering actor to cover the base reserve (currently 1 XLM) needed to create and maintain a G-account. Since Contract Accounts cannot pay fees or reserves directly, they are unable to initiate this process.

Why This Matters

For Classic G-accounts, it’s common practice to check if a recipient already exists in the ledger before sending a payment. If not, the sender automatically creates and funds the account. Multiple SDF members have confirmed that this is a fundamental behavior across most Classic wallets.

To maintain feature parity and improve usability, Contract Accounts should support a similar flow.

Next Steps

Since this requires a protocol change, we need to explore potential approaches. Looking forward to feedback and ideas on possible solutions! 🚀

[dmkozh]

Thanks for opening this discussion.

One high level consideration regarding feasibility of this feature is whether a classic account is involved in the flow at any point. Since currently it's not possible to submit a transaction without a classic account paying the fees, the flow could be implemented without any protocol changes in almost the same fashion as it would be implemented for classic payments (via an additional transaction that creates the destination account). The main downside compared to classic is that this would require 2 sequential transactions, which increases the latency. Still, I wouldn't discard this option given its immediacy.

If we were to go with a protocol change for this, after thinking about this for a bit I think the following seems to be the best option: modify SAC to create a new G-account in case if it performs a transfer of 1+ XLM to a non-existing G-address. This way the transaction source pays as much fee as it would in case if no new account was created, and the transfer source funds the new account as intended. The only caveat is that transfers of <1 XLM to non-existent addresses will fail, which doesn't seem like a big issue to me (a new account has to take 1 XLM from somewhere). Also, this doesn't provide an explicit 'create account' interface to Soroban, but it doesn't seem to me like that has to be a requirement (please let me know if you think otherwise).

[tomerweller]

Since currently it's not possible to submit a transaction without a classic account paying the fees, the flow could be implemented without any protocol changes in almost the same fashion as it would be implemented for classic payments

@dmkozh, been thinking about this some more and I'm not sure this is accurate. Aren't you conflating the origin of tx fee XLM with the origin of the new XLM balance? What if the contract account wants to create a g-account using their own XLM balance. How would that be implemented?

[dmkozh]

What if the contract account wants to create a g-account using their own XLM balance. How would that be implemented?

Contract account sends some balance or gives an allowance to the relayer service, then relayer service uses that balance to pay the fees and to e.g. create accounts. Basically there is nothing specific to a particular operation here - unless the relayer service is completely free, there should be a way for the users to fund it. If it is completely free for the users, then 1 XLM will indeed be withdrawn from the relayer's own balance.

[marcelosalloum]

What if the contract account wants to create a g-account using their own XLM balance. How would that be implemented?

Contract account sends some balance or gives an allowance to the relayer service, then relayer service uses that balance to pay the fees and to e.g. create accounts. Basically there is nothing specific to a particular operation here - unless the relayer service is completely free, there should be a way for the users to fund it. If it is completely free for the users, then 1 XLM will indeed be withdrawn from the relayer's own balance.

This kind of approach could fit into the wallet-backend, but I'm afraid it could become a scope creep. @JakeUrban, what are your thoughts on a G-account creation service? That could involve the relayer keeping tabs of balances per client, a concept that doesn't exist yet.

[dmkozh]

what are your thoughts on a G-account creation service? That could involve the relayer keeping tabs of balances per client, a concept that doesn't exist yet.

To be clear, I don't think that balance keeping is specific to the account creation; account creation is just a small use case that a relayer service could provide. Giving the users an unlimited fee support for sending Soroban txs comes with endless abuse possibilities, so I think providing the service at scale would require supporting balance tracking in some fashion.

[JakeUrban]

The wallet-backend has an account creation endpoint today, which uses the configured G account to fund the requested address. I'd like to remove the submission functionality from the wallet-backend, but we could keep the functionality of building and signing the transaction that creates the account.

[leighmcculloch]

For Classic G-accounts, it’s common practice to check if a recipient already exists in the ledger before sending a payment. If not, the sender automatically creates and funds the account.

@marcelosalloum @tomerweller Is the scenario being described here for the native asset only, or for issued assets as well? How does the use case handle issued assets with trust lines? Do existing integrators use claimable balances at all for this?

The main benefit to supporting contracts creating accounts is so that account creation could occur at the same time as a payment. But account creation on its own isn't enough for setting up an account for the delivery of a non-native asset. The account will also need to create their trust line.

So I think if we hope to solve the problem of create account and pay in a single transaction, we need more than just create account added to Soroban, we also need functions for adding trust lines, where both the sender and the receiver can sign soroban auths to be included in the transaction.

The network has another solution for sending to accounts that don't exist: claimable balances. Would that be appropriate to consider instead?

But, back to the question at the beginning of my comment, we need to go into more detail on this scenario to better understand the use case.

[marcelosalloum]

Great, that gives us a relatively lean scope, where the SAC solution should work great.

[marcelosalloum]

modify SAC to create a new G-account in case if it performs a transfer of 1+ XLM to a non-existing G-address. This way the transaction source pays as much fee as it would in case if no new account was created, and the transfer source funds the new account as intended. The only caveat is that transfers of <1 XLM to non-existent addresses will fail, which doesn't seem like a big issue to me (a new account has to take 1 XLM from somewhere)

It seems we’ve aligned around Dima’s original proposal, which appears to address the use case effectively.

Unless there are objections, we can treat this as the agreed-upon solution. Please 👍 if you’re on board with this direction @leighmcculloch, @dmkozh, @tomerweller, @JakeUrban.

[marcelosalloum]

In an offline conversation with Leigh, he raised a good point about feature parity—both between different SACs and between SAC and Classic operations. A few scenarios we should consider carefully:

1. If a client submits a Classic paymentOp in lumens to a non-existent account, should that behave the same as an SAC XLM transfer?
2. Should non-native SAC transfers also be updated to follow the same behavior as the XLM SAC transfer?

Curious to hear everyone’s thoughts on how far we want to align behaviors across these cases.

[marcelosalloum]

1. If a client submits a Classic paymentOp in lumens to a non-existent account, should that behave the same as an SAC XLM transfer?

Personally, I think this ☝️ could be dangerous, as it'd change a pretty old behavior out of the blue...

[dmkozh]

If a client submits a Classic paymentOp in lumens to a non-existent account, should that behave the same as an SAC XLM transfer?

I don't think this is a requirement for feature parity. There will be feature parity between classic ops and SAC as a whole - as in, it is possible to create a new account both on classic and with SAC. I don't think the parity between specifically payment op and specifically SAC transfer has ever been a requirement and I don't think it needs to be. It's also important to consider the need for this as a feature - I'd say we shouldn't add more features to the classic protocol unless there is a clear use case. There are already workflows built around createAccount and I don't see what value would changing the payment op semantics provide.

Should non-native SAC transfers also be updated to follow the same behavior as the XLM SAC transfer?

This has already been brought up, hasn't it? This is out of scope of this proposal and is generally problematic. To be more specific, I think this is simply impossible until either trustlines are no longer a requirement for G-accounts, or until state archival is implemented for trustlines. What is possible to do, is to provide a way to create trustlines from Soroban (authorized by the trustline owner). This still won't be consistent with XLM transfer because of the authorization/reserve price issue. And I think this should be a separate discussion.