Stellar: contract invocations

[marcelosalloum]

Describe the feature

I've reviewed the early efforts of the Stellar relayer and I can see payment operations are the only ones currently supported:

openzeppelin-relayer/src/models/transaction/stellar_types.rs

Lines 114 to 120 in 9e2c44c

	pub enum OperationSpec {
	Payment {
	destination: String,
	amount: i64,
	asset: AssetSpec,
	},
	}

Q1: How will the payload look like for contract invocations?

Q2: Also, are you thinking of only supporting operations where the relayer is the signer? What if the client account needs to sign the transaction as well?

Additional context

Marcelo from SDF here 👋

[dylankilkenny]

Hi @marcelosalloum!

How will the payload look like for contract invocations?

TBD, this is still alpha software so the design is likely to change, but it might end up looking something like this initially

pub enum OperationSpec {  
    Payment {   
        destination: String,   
        amount: i64,   
        asset: AssetSpec,   
    },  
    InvokeHostFunction {
        contract_address: String,
        function_name: String,
        args: Vec<ScVal>,
        auth: Vec<SorobanAuthorizationEntry>,
    },
}

We may also add a raw_xdr field to support transactions/operations which are not strictly defined by the payload interface.

Also, are you thinking of only supporting operations where the relayer is the signer? What if the client account needs to sign the transaction as well?

When you say the client needs to sign, would having raw_xdr cover that case? Or is there a different flow in mind

[marcelosalloum]

Hello @dylankilkenny,

✅ The generic approach is pretty useful as it enables support to virtually any kind of operation.
✅ The format of the InvokeHostFunction seems good. NOTE: The SorobanAuthorizationEntry format can get a bit complex, and the default serializers typically parse to/from XDR strings. For easier integration, I imagine clients would be sending XDR representations of these auth entries.

💭 Regarding overall usage: there will be cases where a client wants to send a payment from their own account but prefers the Relayer to handle submission and monitoring. In the Stellar ecosystem, this is typically achieved by the server providing a channel account, either:

• by building the transaction in advance, or
• by sharing the channel account’s G-address so the client can construct the transaction themselves.

Option 1: Server Builds the Transaction Using a Channel Account

sequenceDiagram
    participant Client
    participant Relayer
    participant Stellar RPC

    Client->>+Relayer: Sends payment payload with `sourceAccount: client`
    Relayer->>Relayer: Builds tx using an available ChannelAccount
    Relayer-->>-Client: Returns built tx with the requested operation payload
    Client->>Client: Signs the Tx
    Client->>Relayer: Sends the signed tx
    Relayer-->>Client: ACK
    Relayer->>Relayer: Signs the tx
    Relayer->>+Stellar RPC: Submits the tx
    Stellar RPC-->>-Relayer: ACK

Loading

Option 2: Server Allocates a Channel Account for the Client

sequenceDiagram
    participant Client
    participant Relayer
    participant Stellar RPC

    Client->>+Relayer: Asks for a channel account
    Relayer-->>-Client: Returns the G-address of an available channel account
    Client->>Client: Builds & signs the Tx using the channelAccount
    Client->>Relayer: Sends the signed tx
    Relayer-->>Client: ACK
    Relayer->>Relayer: Signs the tx
    Relayer->>+Stellar RPC: Submits the tx
    Stellar RPC-->>-Relayer: ACK

Loading

Let me know if that aligns with your thinking or if you have any questions!

[marcelosalloum]

Just to be clear: in terms of priority, InvokeHostFunction support is likely what the ecosystem needs the most right now. The flows I shared in the diagrams are definitely must-haves but less urgent than contract invocation support