Fetching state for proving holding X amount of custom fungible tokens

[pastel summit]

Hi, how can I query the current state to retrieve the latest proof of an account holding at least X amount of a custom fungible token? My goal is to generate a proof within a zkProgram that verifies whether a user holds more than X amount of a specific custom fungible token. Should I use the Node API for this? Thanks!

[spring ginkgo]

Can you ever trust a proof of blockchain state in a zkProgram? How can you verify that it came from the real Mina?

how can I query the current state to retrieve the latest proof of an account holding at least X amount of a custom fungible token
I'm not sure exactly, but it seems like directionally what you mean is a merkle proof for a specific token balances tree? I don't know what tools our nodes have for access to that.

[pastel summit]

On Ethereum, you provide the circuit with the relevant Merkle proof for a given data point, traverse the root, and compare it with the valid one retrieved from an RPC, light client, or another source. I believe it would be much more simpler on Mina since it should be already snarkified

It's the concept used in Nori, zk-coprocessors, interop solutions and more

[spring ginkgo]

I see. Yes that sounds reasonable, but I don't know what options the node provides. Let me see if I can find out and get back to you.

[spring ginkgo]

There is a query on the Mina node graphQL schema called snarkedLedgerAccountMembership that takes an account and a token id and returns a membership proof

I guess the Mina node graphQL api is pretty obtuse and there's not a good schema explorer for it?

[pastel summit]

That's great, thanks for sharing!

What about zkApp's state? Specifically asking for custom tokens, receiving a zkApp's state proof that user has X amount of custom tokens?

[lunar lagoon]

It is a little bit tricky now as you cannot make a precondition on the circulation account for FungibleToken - it will be blocked by the logic of FungibleToken. You have two options:

• get the circulation from the FungibleToken method, risking that the circulation will be changed before your tx will be included in the block and the tx will fail
• track the circulation yourself for your tokens, like in the example where 25% of the tokens holding is required to bid on the auction: https://github.com/minadevelopersalliance/nft-standard/blob/main/src/marketplace/nft-shares.ts#L322
  @wanton ruin probably this problem with precondition on circulation should be fixed in the next version

[pastel summit]

Thanks for the information. I would also like to ask would it be possible to verify the given above snarked ledger account membership proof in a zkProgram? For example if the token amount is > or < X. What about the verification keys?

[lunar lagoon]

Theoretically, yes, but you have two issues:

• No code examples exist
• You need to check the proof against L1 commitment
  What I do on the NFT standard is I add to the off-chain proof generated by the ZkProgram the PublicKey of the Oracle contract and then I verify the L1 state that this proof is relying on in the Oracle contract.
  https://github.com/minadevelopersalliance/nft-standard/blob/main/src/contracts/collection.ts#L485

You can, of course, rely on RPC, but RPC can fake the result.

[spring ginkgo]

The snarkedLedgerAccountMemebership proof comes from Mina but you can input a custom token ID. This seems like the right way to prove that a user has X amount of a specific token. Proving ZkApp state is another story though. Can you break down what you need ZkApp state for, vs. what you need ledger data for? I agree with DFST about accessing circulation, but I don't see the relationship between token circulation and a specific account's token balance.

[lunar lagoon]

You need circulation to calculate % of token ownership for cases when the ownership of more than 10%, 25%, or 50% gives special rights, similar to the rights attached to the shares in the corporate world

[pastel summit]

Yes, as you mentioned, I asked about two different cases:

1- Obtaining proof of an account's state for a custom fungible token.
2- Obtaining proof of an account's state for native tokens.

Both cases are for generating a client-side proof to verify whether a user's balance is greater than X.

That's why I wanted to ask if it's possible to use the proof fetched from the snarked ledger or in a zkProgram. The same question for the state of the custom fungible token as well.

[sacred star]

I mean both are much simpler to do with a balance precondition, if you end up settling your proof to Mina