Market Account Info Deserialization

[bkw1491]

I'm writing a user-friendly .NET wrapper for the MonacoProtocol- I have extensive experience developing for other sports betting APIs but I am new to web3.

I've used the Solana JSON RPC API to get the data from one of your on-chain accounts for a particular market and received this response:

{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "apiVersion": "1.16.17",
      "slot": 224254400
    },
    "value": {
      "data": [
        "277VNwDjxpr87rCPIajwDOXOtyqHX...\u003d",
        "base64"
      ],
      "executable": false,
      "lamports": 6124800,
      "owner": "monacoUXKtUi6vKsQwaLyxmXKSievfNWEcYXTgkbCih",
      "rentEpoch": 0,
      "space": 752
    }
  },
  "id": 0
}

I am assuming what I am after is somewhere in that Base64 encoded string, which I have converted to bytes? But I am not sure where to go from there.

I am assuming the protocol is based on the Anchor framework, which from what I have read, uses Borsh serialization. Also, according to this page in the Anchor docs "The first 8 bytes are reserved for a unique account discriminator, self-described by the first 8 bytes of the SHA256 of the account’s Rust ident.". I am not sure if this is relevant in this case.

Regardless, what do I do for the rest of the data? Is there some kind of schema? If so, what order are the properties in? Am I correct in saying I need to know the order for Borsh serialization?

For reference, the corresponding type in your TypeScript client looks like this (again, I'm assuming data to populate these fields is somewhere in that Base64 encoded string):

export type MarketAccount = {
  authority: PublicKey;
  decimalLimit: number;
  escrowAccountBump: number;
  eventAccount: PublicKey;
  marketLockTimestamp: BN;
  marketOutcomesCount: number;
  marketSettleTimestamp?: BN;
  marketStatus: MarketStatus;
  marketType: PublicKey;
  marketTypeDiscriminator: string;
  marketTypeValue: string;
  marketWinningOutcomeIndex?: number;
  mintAccount: PublicKey;
  published: boolean;
  suspended: boolean;
  title: string;
  inplay: boolean;
  inplayEnabled: boolean;
  inplayOrderDelay: number;
  eventStartOrderBehaviour: MarketOrderBehaviour;
  marketLockOrderBehaviour: MarketOrderBehaviour;
  eventStartTimestamp: BN;
  unsettledAccountsCount: number;
  unclosedAccountsCount: number;
  version: number;
};

I may be doing this completely wrong, please forgive my ignorance- I'm very new to web3 development. Thank you for your help.

[pawel-betdex]

Hey. You are definitely on the right track.

Is there some kind of schema? If so, what order are the properties in? Am I correct in saying I need to know the order for Borsh serialization?

Yes. The Rust code of the account is the schema. It dictates types, sizes and order in which everything is serialised/deserialised. Here is the one for the market. You can find others in the same folder. I would probably ignore TypeScript client (or treat it as a guide only) as source of truth as not all types map 1-1 with Rust. Here's some useful code for the data type sizes that we use to initiate accounts.

"The first 8 bytes are reserved for a unique account discriminator, self-described by the first 8 bytes of the SHA256 of the account’s Rust ident.". I am not sure if this is relevant in this case.

You can use those 8bytes to validate if you are deserilising the right thing. I could imagine a smart wrapper in .NET that returns type depending on that signature. However considering that you usually know the type of the account you are dealing with anyway (as public keys of accounts owned by the program are quite intentional) most time you will be simply chopping it off.

Hope that helps.

[bkw1491]

Thank you for the guidance, it's much appreciated. Unfortunately, I have had to go through the pain of implementing Borsh serialization from scratch.

Just to follow up- for strings, as far as I understand, the first 4 bytes correspond to the uint32 value for the length of the string. Do I use this value to read the subsequent bytes or do I use the maximum lengths that you have set, for example here:

    pub const TYPE_FIELD_MAX_LENGTH: usize = 16;

I would then read 4+4*16 bytes from the buffer, similar to what is defined in these functions:

const VEC_PREFIX_SIZE: usize = 4;
pub const fn vec_size(element_size: usize, length: usize) -> usize {
    VEC_PREFIX_SIZE + element_size * length
}

pub const fn string_size(str_len: usize) -> usize {
    vec_size(CHAR_SIZE, str_len)
}

It's just that when I use the length as defined by the first 4 bytes, I get some ridiculous value. I have assumed the order is the same as the order in which the properties are defined in the Market struct.