XCM enables a way to interact with a chain (write operation) but we still need another subsystem to query the information (read operation). A previous discussion can be found here: XCM as a Standard for Reading And Interacting with Parachains - #19 by gavofyork I would like to kick off the design a…

This looks great - also, in terms of simplicity I’m very much in favor of having basic entry points like execute_program that then can call into different “extensions” of the runtime, rather than trying to bake them all into the language itself. This does effectively make XCQ a turing-complete-with-…

[image] xlc: Program Size: A custom DSL can be very size efficient and that’s something we want for onchain message passing as we have limited bandwidth for HRMP / XCMP. Can we ensure that the PolkaVM program size are reasonably small that it will not be too costly to send them with HRMP / XCMP? …

It will depend on some implementation details. For example, ink! wasm contract was too big for it to be used by parachains initially and a lot of work was done to reduce the size. I want to ensure we take the lesson and build this with program size in mind in the first place. But yeah I see no reas…

Very valuable use case to support DOT => USDT + USDC conversion Get the DOT/USDT + DOT/USDC rates from AssetHub so that this adhoc “10” here is not hardcoded Set Asset Rates for Treasury Assets

I think looking through the benchmarks for PolkaVM would be a good place to compare binary sizes.

I guess we could build some onchain asset metadata mechanism and have XCQ be able to query token info from there.

Great initiative! One that I’ve been taking a look into myself, but bigger priorities came up :sweat_smile:. These extensions remind me of dialects . XCM does not have dialects (though it allows arbitrary execution via the Transact escape hatch) and the XCVM is not turing-complete. That is by desig…

Then, new queries can be added via an RFC process like the one for XCM This is exactly something I want to avoid. The XCM RFC process takes forever and is blocking innovations. Then, both XCQ and XCM should be managed by either an ecosystem collective or an XC collective, to make sure we all ag…

I have the very first PoC running XCQ/poc at master · open-web3-stack/XCQ Cross-Consensus Query Language for Polkadot. Contribute to open-web3-stack/XCQ development by creating an account on GitHub. [Screenshot 2024-05-02 at 9.48.46 PM] I have a simple Polk…

If the XCM RFC process takes forever then we should make it go faster :grin:. The polkadot-sdk release process also takes forever, we just need to make things faster. I agree the maybe-not-standard needs to live in the wild before we can actually standardize things. I think trying out a different…

Cross-Consensus Query Language (XCQ)

Tech Talk

tymat April 27, 2024, 7:19am 3

If the plan is to use RISC-V then the program sizes will be small. The question is whether or not endianness is going to matter much (EVM is big endian)

Topic		Replies	Views
XCM as a Standard for Reading And Interacting with Parachains Tech Talk xcm	17	2460	April 28, 2023
XCM user and developer experience improvements Tech Talk xcm	24	2219	October 23, 2024
Major Milestone for Solidity Smart Contracts: First Part of the Preview Release Now Live on Kusama Ecosystem smart-contracts , documentation	27	1731	July 24, 2025
ParaSpell✨ - Your go to XCM Tool stack xcm	4	253	July 4, 2025
Enhancing cross-chain experience of your dApps with revolutionary XCM Tool set from ParaSpell✨ Tech Talk xcm	9	729	October 29, 2024

Cross-Consensus Query Language (XCQ)

Related topics