Usage of mempool API for wallets

[SebastienGllmt]

I'm looking into using the mempool API provided by Ogmios for usage in wallets. However, I couldn't find answers to these three questions:

1. Are all the txs in the mempool validated to a certain degree? (ex: if I submit a tx that withdraws from a stake credential that was never registered on-chain or any other tx in the mempool, will it still show up in the mempool or be rejected right away?)
2. Is there a way to get the raw tx CBOR instead of the JSON payload? For our use-case we need raw tx cbor
3. Is the order of txs maintained order between acquire calls? i.e. if tx A appears before tx B in one call, will the order ever be flipped in a following call?

[KtorZ]

Ho, hi there!

1. Only valid transaction (from the perspective of the local node) will go in the mempool. The server performs both phase 1 and phase 2 validations, and reject the transaction should any fails.

2. Yes, but only on master currently. I'll publish the new version as soon as I am done reworking the API reference documentation (which should seemingly make the this kind of details easier to find). On master, every transaction now includes an new field raw which corresponds to the raw tx CBOR: https://github.com/CardanoSolutions/ogmios/blob/master/docs/static/ogmios.wsp.json#L5669

3. That is a good question. The protocol certainly does not enforce that so, the only correct answer would be: no. It is an "implementation detail" and therefore isn't guaranteed. As far as know though, the server implementation uses an ordered list, and new transaction are added at a higher index so I would expect the order to be preserved, though with gaps: some txs may be removed between two calls of acquire / reacquire.

[SebastienGllmt]

2. Awesome, looking forward to it
3. Hmm, okay. It makes pagination trickier. For pagination, I'm thinking of making the endpoint take an address as an input, and the return type is

{
    hash: string,
    txs: string[] // string is cbor
}

Then I can use a hash function over the cbor array where the order of data matters. That way, a client can paginate based off the index in the txs and if the hash changes part-way through the pagination, it can restart the pagination from index 0.

[KtorZ]

@SebastienGllmt I am not sure to get your point about pagination here 🤔 ? Surely, it's a mempool so there won't be many transactions in it. Somewhere between few hundreds and a couple and the whole size is bounded: ~180kb of raw binary data, so maybe triple that with the JSON overhead + hex encoding; so really not something that isn't manageable by a client to ingest all at once I suppose.

Otherwise, yes, paginating the mempool here is a bit tricky since it's by essence a volatile list-like data-structure where things can be removed at arbitrary position in the list. You could definitely get a hash as kind of checksum or, perhaps also consider having the client explicitly acquire some state? For example, have a way for the client to "acquire" this hash (e.g. via an endpoint) and have it provide this hash as a request argument for any paginated request. If the hash ever changes, then the server can properly fail with a relevant error message. This make the burden of checking on the server, so that client won't forget and be surprised later because they forgot to check the hash in responses.