Seeking champions for grant fund #190 BlockTravel - Transcation Compliance Framework
Good Morning Grants discussion group.
Kurtis Wright, COO of Block Infrastructure here, along with CEO Richard Beverley, CTO Josh Mahmud & CDO Suhu Karur.
We are seeking champions for Dev Fund proposal #190: BlockTravel - Transcation Compliance Framework
https://github.com/canton-foundation/canton-dev-fund/pull/190
BlockTravel is a pre-transaction compliance framework designed for digital asset, stablecoin, cross-border payment and counter party settlement environments, which is 12 months in the making.
Following a similar approach to our Dev fund proposal #189: BlocklD - Network Based Identity Verification and Data Sharing https://github.com/canton-foundation/canton-dev-fund/pull/189
We have been working with a select group of financial services regulators, financial intelligence units, information commissioners/data protection authorities, governments and multinational digital asset organisations.
This outreach across multiple jurisdictions and international financial centres has helped us to gain insights and feedback to help shape and build out our POC in the Canton DevNet environment. This was recently demonstrated to a select group of financial institutions and operators on the Canton network.
Last week we were approved on TestNet and are close to the point of providing a secondary round of demonstrations to a wider range of participants on the Canton network through our TestNet build.
This solution has also been presented to the partnerships, developer relations, ecosystem and network growth teams at Digital Asset, along with a c-suite member at the Canton Foundation.
Parties who are interested in becoming a champion, we are happy to provide a demonstration and walk through of the solution.
Further details of the solution are provided below.
Were looking forward to further discussions regrading our proposal with you all.
Abstract
BlockTravel is a pre-transaction compliance framework designed for digital asset, stablecoin, and cross-border payment environments.
At a high level, the system introduces the concept of compliance checks occurring before transaction finalisation, rather than after. This enables financial participants to better align transaction processing with regulatory expectations.
When integrated into distributed ledger environments, BlockTravel acts as an external decisioning service that determines whether a transaction may proceed based on defined compliance criteria.
Note: This public version intentionally omits implementation details, internal logic, and proprietary methodologies.
1. Objective
Digital asset markets continue to expand, but compliance approaches remain inconsistent across participants.
Common industry challenges include:
- Fragmented compliance tooling and standards
- Variability in regulatory interpretation across jurisdictions
- Operational complexity when coordinating multi-party transactions
- Delays introduced by post-event compliance processes
BlockTravel is designed to explore a different model:
- Pre-condition checks before execution
- Consistent decision outcomes across participants
- Reduced operational ambiguity in transaction handling
This proposal focuses on enabling a standardised interface for compliance decisioning within distributed systems.
2. Conceptual Model
At a conceptual level, the system introduces three high-level components:
2.1 Transaction Gating Interface
A generic interface that allows applications to:
- Submit a transaction request for evaluation
- Receive a binary or structured decision outcome
- Proceed or halt execution based on that outcome
No assumptions are made about:
- Data structure
- Internal evaluation logic
- Underlying infrastructure
2.2 External Decisioning Service
A separate service evaluates transaction requests against:
- Regulatory considerations
- Risk parameters
- Participant-defined policies
The exact mechanisms used to generate decisions are not disclosed.
2.3 Off-System Data Handling
Sensitive data is not exposed within shared environments.
Instead:
- References or identifiers may be used
- Data processing occurs outside shared execution layers
Only minimal outcome data is returned
3. Integration Approach
The system is designed to integrate in a non-intrusive, additive manner:
- Existing applications can optionally invoke compliance checks
- No changes to core transaction logic are required
- The model supports multiple implementation environments
The goal is to provide a plug-in style compliance layer, rather than a replacement for existing infrastructure.
4. Design Principles
The proposal is guided by the following high-level principles:
Privacy-Aware Design
Sensitive information should not be broadly distributed or exposed unnecessarily.
Deterministic Outcomes
Transactions should have clear, unambiguous outcomes based on pre-defined criteria.
Interoperability
The model should support multiple systems, standards, and participant types.
Extensibility
The framework should allow for future adaptation without requiring structural redesign.
5. Milestones (High-Level)
Phase 1 — Foundational Interfaces
- Define generic compliance request/response patterns
- Establish integration examples
- Demonstrate basic transaction gating
Phase 2 — Expanded Evaluation Capabilities
- Support broader categories of compliance checks
- Demonstrate multi-party interaction scenarios
- Validate performance under controlled conditions
Phase 3 — Observability & Reporting
- Introduce visibility mechanisms for authorised observers
- Demonstrate auditability of decisions
- Ensure alignment with privacy expectations
Phase 4 — Production Readiness
- Validate system robustness
- Conduct external testing and review
Prepare for wider adoption
6. Compatibility
The framework is designed to be:
- Backward compatible with existing systems
- Optional to adopt
- Non-disruptive to current workflows
No breaking changes are introduced.
7. Funding
Milestone 1 (Foundation): 175,000 CC upon committee acceptance
Milestone 2 (Compliance Intelligence): 175,000 CC upon committee acceptance
Milestone 3 (Network Scale): 175,000 CC upon committee acceptance
Milestone 4 (Production Readiness): 175,000 CC upon final release and acceptance
8. Motivation
The evolution of digital financial systems requires greater coordination between transaction execution and compliance processes.
Current approaches often treat compliance as:
- A separate function
- A delayed process
- A reactive control
This proposal explores a model where compliance becomes a pre-condition to execution, improving clarity and operational alignment.
9. Rationale (High-Level)
Why pre-transaction checks?
To reduce ambiguity in transaction outcomes and align execution with predefined conditions.
Why a shared interface?
To reduce duplication of effort across participants and systems.
Why external decisioning?
To allow flexibility in how compliance logic is defined and maintained.
10. Go To Market Strategy
Phase 1, Proving the Technology
This phase will test:
- Core integrations (including native interaction with the Canton Network)
- Regulatory screening (sanctions, AML/CTF, PEPs)
- Institution-specific, KYC-driven policy screening
Phase 2, Expansion across the Canton Network
With the technology proven, Block Infrastructure will present the working solution to additional Canton Network participants, positioning BlockTravel as a compliance oracle on for all digital asset transactions.
Phase 3, Adjacent Verticals
Once established within digital assets, BlockTravel will expand across adjacent asset classes operating on the Canton Network
Important Notice
This document is a public, redacted version of the full proposal.
It intentionally excludes:
- Technical architecture
- Data models
- Processing logic
- Decisioning methodologies
- Performance characteristics
- Proprietary innovations
Its purpose is to provide conceptual visibility only, not implementation guidance. For access to the full non-redacted version please contact Block Infrastructure via the email address josh@...
