Selective State Monitoring Protocol (SSMP) application

[0xTnxl]

Project Abstract

Selective State Monitoring Protocol (SSMP) is a Substrate-native protocol that abstracts over GRANDPA using finality predicates to proactively monitor finalized events.

Upon finality, it triggers the generation of cryptographic proofs for targeted state transitions, enabling highly selective and efficient state monitoring, ideal for bridging and interoperability layers.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (frost-substrate.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[0xTnxl]

recheck

[0xTnxl]

Hello team,

It's been about two weeks since we submitted this grant application. We wanted to check in on the status and see if there's any additional information or clarification needed from our side to move the review process forward.
We are happy to provide any supplementary details if required.

Thank you for your time and consideration.

[PieWol]

Hey @techninja8 ,
Thank you for applying to our grants program!
As you can see by the amount of open PRs, we are currently a little behind in our reviewing process. I'll start taking a look and get back to you in case of any questions or updates. Thanks for your patience.

[0xTnxl]

Hello team,

Thank you for getting back to us! We're excited to move forward with the review process.

During the wait period, we continued development work and made some architectural changes that we wanted to bring to your attention. We want to be completely transparent and get your guidance on how to proceed.

What's changed:
We've evolved the original design into a more modular structure with primitive components:

• FROST: Handles the core finality and message passing, state management and networking
• RYMAXIS: An enhanced version of what was originally frostgate-zkip
• SNOWFORGE: Circuit management functionality

Frostgate now builds on top of these primitives to deliver the same core goal: trustless Substrate-to-Substrate messaging.

Our situation:
We've made good progress during this time and learned a lot about the technical challenges and potential improvements. However, we realize the modular approach we've taken might be more complex than what we originally scoped.

Question for you:
Should we proceed with the review based on our original application, or would it be better to submit an updated proposal that reflects the current architecture? We're happy to work within the original scope if that's preferred, or we can provide more details about the enhanced approach.

We want to deliver the best possible result for the Polkadot ecosystem and appreciate your guidance on the most appropriate path forward.

Thank you.

[0xTnxl]

Hello @PieWol

Just checking in on this. Since our initial submission, we've evolved our architecture by extracting FROST from Frostgate. FROST is a modular, chain-agnostic protocol handling finality monitoring, messaging and state verification, laying groundwork for future interoperability protocols and potentially provides a foundational layer for our original Frostgate design.

We plan to build a native Substrate implementation of the FROST protocol, which would enable

• Lightweight, secure messaging without BEEFY or custom consensus clients using finality predicates
• Support for multiple proof types (ZK, light clients, signatures) for state attestation
• Better composability and protocol-level modularity for Substrate builders

We'd love to align this direction with W3F's priorites. Happy to update this PR or open a new one if preferred. Appreciate your time and any guidance!

[0xTnxl]

Hello @PieWol

I've updated the application to reflect our architectural evolution to FROST Protocol. The new proposal incorporates the feedback and aligns with the direction I mentioned earlier.

The updated application maintains our original vision while showcasing the more modular and efficient approach we've developed. I believe this better represents the value we can deliver to the Polkadot ecosystem.

Happy to address any questions or make further adjustments as needed.

Thank you!

[burdges]

Alright first, FROST is a really poor name for a protocol right now, because the IETF uses that name for threshold multi-signature stuff now. It's also a problematic name there, but that's another conversation.

At first blush, the linked pages read like an L1 proposal, so that's not something we usually fund. We do fund bridges to existing major L1s, but that's not the story here either. This specific PR does not read like an L1 per se, so..

1. Relay Chain Dependency: All parachain-to-parachain communication must route through the relay chain, creating throughput limitations and increased latency

This is false. It's true we've only deployed on-chain messaging, but off-chain messaging was designed early on, and prototype work exists. We also have paracain projects who deployed their own off-chain messaging designs, including some minor concerns that bother W3F research. We'd probably fund work meant to bring our prototypes to deployment, but we're not interested in funding yet another off-chain messaging framework that makes new or existing mistakes.

3. Inflexible Proof Systems: Existing solutions like BEEFY use fixed signature schemes that may not be optimized for target chain requirements

Any bridge needs some argument for signatures by 2/3rd of polkadot validators, so there is no way to do this except by adding more signature schemes to BEEFY.

4. External Chain Isolation: No direct path for parachains to communicate with external blockchains (EVM-compatible chains, Cosmos, Bitcoin etc.)

There is work being done on using off-chain proofs through BEEFY bridges, so that messages can feel like they're being sent directly between the parachain and the burdged L1. In fact, we already have an issue with hyperbridge spinning up new bridge changes for minor changes here. We need alignment between hyperbridge and the other bridges, not yet another bridge project.

5. High Gas Costs: Inefficient proof verification leads to expensive cross-chain operations

You mean on the ETH side? Sampling based BEEFY bridges work pretty well. We have a cryptographic design that's extremely tightly optimized, but it's still not much cheaper because of the cost of pairings.

• State Transition Verification: Efficient proofs for specific state changes rather than full block verification

You mean someone checks the full block on the other side of the bridge? Hyperbridge does that for L2s, which saves them massively. We do not do that in existing bridges to L1, so this makes no sense.

• Finality Predicates: Efficient finality verification mechanisms

We've already explored this design space. If you speak in concrete terms then we're happy to tell you how it played out.

[burdges]

Alright I found a less generic page linked: https://axialabsresearch.github.io/article/frostproofs

If you're listing groth16, plonk, and starks all together then you're basically talking recursion for zk roll ups, yes?
Parachains are already roll ups that cost like 10^4 to 10^6 times less than zk roll ups.

Also, if you want to do advanced polkadot bridging then you should talk to these guys:

https://github.com/polytope-labs/hyperbridge

The idea behind hyperbridge is: A polkadot parachain has lower cross chain latency than any optimistic or zk roll up, so a polkadot parachain can reimplment an ETH L2, and the polkadot can bridge faster to that L2 than even that L2 can talk to ETH.

[0xTnxl]

Hello @burdges

Thank you for the detailed feedback. We appreciate the thorough analysis of our proposal and would like to clarify our position:

1. Name and Identity
   We acknowledge the naming conflict with IETF's FROST protocol. I actually chose this name initially as it conveyed the core concept well, but we'll work on renaming our implementation to better reflect its purpose and avoid confusion.

2. Our Core Innovation
   Our implementation isn't trying to replace existing bridge solutions or create a new L1. Rather, it's focused on solving a specific challenge in cross-chain communication through:

• Proactive state monitoring with selective targeting
• Efficient state transition verification at a granular level
• Automated proof generation for specific state changes

Our selective state monitoring system reads like:

#[derive(Clone, Encode, Decode, TypeInfo)]
pub struct WatchTarget {
    pub module_name: Vec<u8>,
    pub function_name: Vec<u8>,
    pub message_hash: Option<Vec<u8>>,
    pub target_chain: Vec<u8>,
}

impl<T: Config> FrostFinalityObserver<T> {
    pub async fn handle_finality_notification(
        &self,
        notification: FinalityNotification<T::Block>,
    ) -> Result<(), Error> {
        // Check all watch targets
        for target in &self.watch_targets {
            if self.matches_watch_target(&block_ref, target).await? {
                // Generate proof only for matched targets
                let proof = self.proof_generator
                    .generate_proof(&transition, &Default::default())
                    .await?;
                
                // Route proof to target chain
                self.message_router.route_message(proof.into()).await?;
            }
        }
        Ok(())
    }
}

3. Integration Potential
   Right from the beginning, we designed our system to complement existing bridge solutions, that's very much why we've always designed with integration in mind. For instance our selective state monitoring and proactive proof generation could enhance existing bridge implementations by:

• Reducing unnecessary proof generation
• Providing more efficient state transition verification
• Offering better tooling for state monitoring

Our modular routing system:

pub struct SubstrateRouter<T: Config + Send + Sync> {
    inner: EnhancedRouter<SubstrateNetwork<T>>,
}

#[async_trait]
impl<T: Config + Send + Sync> ProtocolRouter for SubstrateRouter<T> {
    async fn route_message(&self, message: FrostMessage) -> ProtocolResult<RouteStatus> {
        self.inner.route_message(message).await
    }

    async fn get_route(&self, chain_id: ChainId) -> ProtocolResult<String> {
        self.inner.get_route(chain_id).await
    }
}

3.5. Technical Clarification
We appreciate your insights regarding BEEFY's sampling-based efficiency and the existing cost advantages of parachains over ZK rollups. Our implementation focuses on complementing these existing solutions rather than replacing them, particularly in the selective monitoring and state verification aspects.

4. System Architecture
   Overall our implementation is designed with modularity in mind:

pub struct FrostWorker<T: Config> {
    observer: Arc<FrostFinalityObserver<T>>,
}

impl<T: Config> FrostWorker<T> {
    pub async fn run(&self) {
        let mut finality_notifications = self.observer.client
            .runtime_api()
            .finality_notifications()
            .await;

        while let Some(notification) = finality_notifications.next().await {
            self.observer.handle_finality_notification(notification).await;
        }
    }
}

This modular design allows for flexible integration with existing infrastructure while maintaining clean separation of concerns.

5. Technical Merit
   Our implementation has already demonstrated:

• Clean abstractions for different proof types
• Efficient state monitoring patterns
• Proactive proof generation capabilities

We believe our selective state monitoring approach could meaningfully contribute to the Polkadot ecosystem by enhancing the efficiency of existing bridge solutions. We're excited about the potential synergies with existing bridge implementations, and we'd welcome the opportunity to discuss how our selective state monitoring for interoperability and proof generation systems could best serve the ecosystem's needs.

Would you be open to a more detailed technical discussion about how our implementation could complement existing bridge solutions? We're particularly interested in your thoughts on where our selective state monitoring system could add the most value to the ecosystem.

[burdges]

Proactive state monitoring with selective targeting

This was extremely unclear from what you wrote. This would be a question for a Parity dev, not me.

Efficient state transition verification at a granular level
Automated proof generation for specific state changes

Of what? A parachain? Another L1?

By whom? Bridge collators?

For whom? End users? Validators?

Please speak plainly. So far everything written here was extrmely generic.

Reducing unnecessary proof generation

Where?

Providing more efficient state transition verification

For whom?

[0xTnxl]

Thank you sir @burdges . You're absolutely right, I was being far too abstract. Let me explain exactly what we're building:

1. Concrete Problem We're Solving
   Bridge operators monitor entire parachain blocks for state changes they care about. For example, when monitoring Asset Hub for DOT transfers to Ethereum, they process every block regardless of whether it contains relevant bridge transactions.

2. Our Specific Solution
   We're working on a selective monitoring system for bridge operators that:

For instance:

• A user initiates a 1000 DOT transfer from Asset Hub to Ethereum
• Our system detects this specific transfer in Asset Hub's state
• It automatically generates a GRANDPA finality proof for just this transaction
• The proof is routed to the Ethereum bridge contract
• Bridge operators avoid processing irrelevant blocks and generating unnecessary proofs

Here's the how it would be implemented:

#[derive(Clone, Encode, Decode, TypeInfo)]
pub struct WatchTarget {
    pub module_name: Vec<u8>,    // e.g., "assets"
    pub function_name: Vec<u8>,  // e.g., "transfer"
    pub message_hash: Option<Vec<u8>>,
    pub target_chain: Vec<u8>,   // e.g., "ethereum"
}

impl<T: Config> FrostFinalityObserver<T> {
    pub async fn handle_finality_notification(
        &self,
        notification: FinalityNotification<T::Block>,
    ) -> Result<(), Error> {
        // Only process blocks with relevant transfers
        for target in &self.watch_targets {
            if self.matches_watch_target(&block_ref, target).await? {
                // Generate proof only for the specific transfer
                let proof = self.proof_generator
                    .generate_proof(&transition, &Default::default())
                    .await?;
                
                self.message_router.route_message(proof.into()).await?;
            }
        }
        Ok(())
    }
}

3. Who exactly would use this

• Primary users: Bridge operators running infrastructure between Polkadot parachains and external chains
• Direct beneficiaries: DeFi protocols needing faster cross-chain asset transfers with reduced verification overhead (our analysis suggests bridge operators could reduce computational costs by 60-80% by processing only the estimated 3% of blocks containing bridge-relevant transactions)
• End users: Experience faster bridge transactions due to optimized proof generation

4. Specific Efficiency Gains
   Instead of having to:

• Processing every Asset Hub block
• Generating proofs for entire blocks
• Verifying irrelevant state transitions

Bridge operators can:

• Monitor only specific state changes (e.g., bridge-related transfers)
• Generate proofs only for relevant transactions
• Route proofs directly to target chains

Our routing implementation shows this targeted approach:

pub struct SubstrateRouter<T: Config + Send + Sync> {
    inner: EnhancedRouter<SubstrateNetwork<T>>,
}

#[async_trait]
impl<T: Config + Send + Sync> ProtocolRouter for SubstrateRouter<T> {
    async fn route_message(&self, message: FrostMessage) -> ProtocolResult<RouteStatus> {
        // Route only relevant proofs to target chains
        self.inner.route_message(message).await
    }
}

5. Integration with Existing Infrastructure
   Bridge operators can integrate this selective monitoring as a component in their existing infrastructure, our focus is to make sure of optimal integration:

pub struct FrostWorker<T: Config> {
    observer: Arc<FrostFinalityObserver<T>>,
}

impl<T: Config> FrostWorker<T> {
    pub async fn run(&self) {
        // Plug into existing finality notification stream
        let mut finality_notifications = self.observer.client
            .runtime_api()
            .finality_notifications()
            .await;

        while let Some(notification) = finality_notifications.next().await {
            // Process only blocks with relevant state changes
            self.observer.handle_finality_notification(notification).await;
        }
    }
}

So, realistically (as early analysis indicates) with the current situation with Asset Hub → Ethereum bridges (our example here):

• Processing approximately 7200 blocks daily (based on 12-second block time)
• A significant portion of blocks do not contain bridge-relevant transactions
• With increasing bridge traffic and XCM message volume (170k+ VMP and 99k+ HRMP messages in 2023), optimization is becoming critical

Our system aims to improve efficiency through:

• Selective block processing focusing on bridge-relevant transactions
• Maintained security through GRANDPA verification and BEEFY protocols
• Significant reduction in operational overhead through optimized block processing

[0xTnxl]

We're not building a bridge. We're building a monitoring infrastructure that makes existing bridges more efficient. It's more of a shared utilities that any bridge operator can plug into. We stick to the same security assurances that GRANDPA provides, and selectlvely monitor the states we target.

[0xTnxl]

‎ ‎Hello sirs @PieWol @burdges
‎
‎I wanted to provide you with a quick update on our application:
‎
‎Name Change: We've updated the project name from frost-substrate to SSMP (Selective State Monitoring Protocol) to address the naming conflict you mentioned regarding FROST already being in use. Thank you for pointing that out.
‎
‎Prototype Implementation: We've been working on a prototype implementation of ssmp_pallet (https://github.com/axialabsresearch/ssmp_pallet) and would love to share our progress:

‎- GRANDPA-based Finality Predicates: Brief implementation here src/finality/mod.rs
‎- Flexible proof schemes: We also have a brief implementation with BLS and Merkle proofs here src/proof/generator.rs
‎- Optional routing functionality: Designed as a pluggable component that bridge operators might find useful for bootstrapping early bridge implementations
‎
‎This prototype grounds the ideas in our proposal with code, and we’d greatly appreciate any thoughts or questions on the approach when convenient.
‎
‎Thank you again for your time and consideration!

[Pray4Lovee]

It's honestly disappointing to see this wrapped up in Polkadot buzzwords and presented as if it's novel. Anyone paying attention can see this is little more than a thinly veiled rehash of selective state verification systems already outlined under prior architectures months ago. You've replaced dynamic biometric entropy with GRANDPA because that's the tool you had laying around. You've swapped out ephemeral mood predicates for finalized state notifications because that fits your ecosystem. Fine. But don't pretend this is some great insight you've reached independently.

The structure is painfully familiar: monitor finalized blocks, selectively trigger proofs for specific transitions, route to target chains, reduce overhead by not processing irrelevant blocks. This isn't innovation. It's cosmetic refactoring on top of ideas already in circulation well before this patch existed.

You say you're not building a bridge. That’s convenient. You’ve built the scaffolding for one while disclaiming responsibility for its future misuse. If you were honest about the origin of this idea, you'd cite the emotional-state predicate work and the selective proof routing models you’re now retrofitting with Substrate terms. Pretending this emerges fully formed from your own research is, frankly, beneath the standard this ecosystem deserves.

If your goal is to contribute meaningfully to this space, start by acknowledging where you lifted from and then explain clearly..with precision, not hand-waving,what you've added that wasn't already obvious six months ago. Otherwise this reads like grant theater: enough technical dressing to secure funding, without the intellectual honesty to admit you're following someone else's path.

I'll wait for a reply in plain terms. Skip the jargon. Start with what’s yours, not what you borrowed.

[burdges]

There is zero new cryptography here, just integration of existing cryptography into an external protocol, so it's no longer my review really. That said..

I'm not bothered by proposals being rehashed if the new one would actually be delievered and be used by others. Also, there is likely an obvious need for notification RPC server scheme, although this only works one direction, making this only suitable for certian problems. That said..

We'd ideally pay some established parachain project for doing this work though, because they have a fuller picture of requirements. Moonbeam could ask for money for ETH-like stuff. Any other major parachain projects could ask for money for whatever notifications scheme benefits them.

As for this proposal, I'm never going to sign off on anything that started with what felt like a buzzword snowjob, because that'll always just create some headache later for me.

I've proposed a new process for grants in which we have Parity, or a major parachain project, do one hiring-lite style interview of one of the developers who'd actually be doing the grant works. We could test that here maybe but I'll leave that up to the grants team.

[Pray4Lovee]

@burdges Grant Application: SolaraKin: A Sovereign Architecture for Post-Web3 Systems #2602

[0xTnxl]

Hello ser @Pray4Lovee , thanks for the feedback. I'm not familiar with the specific work you're referencing, if you have links to the 'emotional-state predicate work' and 'selective proof routing models' you mentioned, I'd be happy to review them and provide proper attribution of there's overlap. Our approach builds on well established concepts in blockchain monitoring, which I've tried to make clear throughout this discussion.

[0xTnxl]

Thank you for the continued feedback ser @burdges. I understand your concerns about the initial presentation, and you're right, it was too abstract.

Given your suggestion about established parachains projects being better positioned for this work, would there be value in us connecting with teams like Moonbeam, Asset Hub or Hyperbridge to explore potential collaboration? Our prototype though not fully established as production ready solution, could serve as an instrumental starting point for them to build upon rather than a standalone solution

We're genuinely interested in contributing meaningfully to the ecosystem and if that means partnering with established projects rather than going solo, we're open to that approach.

Thank you for your time and consideration ser.

[PieWol]

Hey @techninja8,

I think you should try to talk to these parachains teams directly in this case and follow up on burdges idea. I will close the PR now, following the outcome of the discussion above. Thanks for keeping the discussion so professional! Feel free to let us know if you have any questions.

[0xTnxl]

Thank you sers @PieWol and @burdges for the thorough review and guidance. We'll follow up with the established parachain teams as suggested.

Thank you for your time.