services/friendbot: support contract addresses

[kalepail]

What problem does your feature solve?

Contracts can hold value and with the rise of smart wallets being able to airdrop funds to contracts will be increasingly important.

What would you like to see?

e.g. rpc.requestAirdrop(contractId) should work vs:

{
  "type": "https://stellar.org/horizon-errors/bad_request",
  "title": "Bad Request",
  "status": 400,
  "detail": "The request you sent was invalid in some way.",
  "extras": {
    "invalid_field": "addr",
    "reason": "invalid version byte"
  }
}

What alternatives are there?

You have to fund a G-address and then use the SAC interface to move funds from the G-address to your C-address. It's a bit cumbersome.

[leighmcculloch]

I think it makes sense for Friendbot to be able to fund all token holding address types.

However it’s unclear to me how valuable/priority that is, because the main reason folks need the native asset on testnet is to pay fees. Contracts can’t pay fees. Therefore contracts have much less use for native.

For everything else other than fees developers don’t need the native asset, they can use any other issued asset.

Since contracts can’t pay fees, likely a contract developer has a G account and will fund it, and use it to submit transactions involving C. Soon that’ll be an easy command from the cli.

For the edge cases where a developer needs native, they already have a G to get some from. So edge cases have a solution although that’s edge cases, not all devs.

[leighmcculloch]

@kalepail could you elaborate on there situation where you need a C address to have native?

[kalepail]

It's one of the easiest transactions to test with on the dapp side. When you're developing with a smart wallet or working with a contract that will deal in an asset, which is nearly always, having easy ready access to the native token would speed up dev time significantly. Dealing with custom assets is very cumbersome as you have to configure trustlines, flags, actually do the issuing, use the CLI or craft some helper function just to get the assets from the G to C address. The native asset makes that all much simpler as you don't have to fiddle with any of the setup or worry about what kind of address you're sending to.

So my angle is from the devX as smart wallets become more popular, or even as a means to ensure their adoption is smooth and painless this would be a very nice and obvious feature to add. It's honestly quite odd that this doesn't work from someone coming at Stellar from the Soroban-first approach.

In my world most devs new to Stellar will know much more about the C-address than the G-address so we should be optimizing for that narrative vs expecting everyone to know and understand both G and C address quirks.