Opened 01-06-2026 by ayanuali, last activity 4mo ago
This proposal seeks funding to build and open-source the DAML Automated Workflow Evaluator (DAWE), a scenario-based automated security and QA testing framework for DAML applications on Canton.
/proposals/SIG: daml-tooling
2 automated messages from bots hidden. Show bot messages
Nobody has commented on or reviewed this proposal yet.
Sigli.ai is building the on-chain neobank for autonomous AI agents on Canton: programmable identities, wallets, compliance guardrails, and financial execution infrastructure for machines. For the identity, wallet, and payment layers, we are building on existing infrastructure, including Tenzro’s agent identity, MPC wallet, and settlement components, rather than rebuilding primitives from scratch.
What does not yet exist in the Canton ecosystem is a standardised framework for automatically testing and verifying the security of DAML smart contracts before they reach mainnet. Every team building complex DAML applications today writes bespoke test scaffolding by hand, with no shared standard for what a security-verified DAML workflow looks like. For an enterprise deploying financially active smart contracts on an institutional ledger, this is not a minor inconvenience. It is a blocker.
This proposal seeks ~337k CC funding to build and open-source the DAML Automated Workflow Evaluator (DAWE): a scenario-based automated security and QA testing framework for DAML applications on Canton. The grant deliverable is the test harness itself, along with a set of realistic financial workflow examples against which it runs. We are proposing to open-source the testing framework because every serious Canton developer needs it.
AI agents are financially homeless. They can execute code, manage complex workflows, and interact with services autonomously, but they cannot hold money, receive payment, or transact without a human approving every step. That is not automation.
Sigli.ai is building the neobank for AI agents on Canton: identity, wallets, payments, compliance, and yield, built for machines rather than humans. The target customer is an enterprise: a bank, asset manager, treasury desk, or financial infrastructure provider that wants to deploy financially autonomous agents in a way that satisfies governance committees, internal security reviews, and regulatory requirements.
For the underlying infrastructure, we are building on what already exists:
Tenzro is our current preferred provider for these components. Where any component is unavailable or does not meet requirements, we will substitute equivalent infrastructure, whether from Canton’s own emerging standards or from alternative providers. The DAWE grant deliverable itself has no dependency on Tenzro or any specific third-party infrastructure.
The gap we are addressing is not in any of these layers. It is a cross-cutting need that every team building complex DAML applications on Canton faces: a standard framework for automatically testing and verifying the security of DAML smart contracts before they reach mainnet. That framework does not exist. We are building it, for ourselves and for the ecosystem.
Canton and DAML give developers strong formal guarantees at the contract level. What they do not provide is a standard framework for:
The consequences of this gap are concrete. In our own experience preparing Sigli’s first enterprise pilots, assembling the security verification documentation required by a prospective institutional client took several weeks of manual effort: hand-written test scripts, narrative descriptions of what each script was testing, screenshots of Sandbox output, and custom formatting to match the client’s internal security review template. None of that work was reusable for the next client. Teams in the Canton ecosystem we have spoken with report the same pattern. One RWA issuer preparing for a third-party security audit estimated that bespoke test documentation accounted for six to eight weeks of their deployment timeline. Another team deploying a compliance monitoring contract delayed their mainnet launch by over a month while preparing evidence packs for their legal and risk committees. These are not edge cases. They are the standard experience for any team taking a DAML application through an institutional procurement process.
Every Canton team building for enterprise clients has to solve this from scratch. The result is inconsistent test coverage, undocumented security assumptions, and bespoke verification processes that slow every serious deployment. The DAWE makes this systematic once, for everyone.
Sigli needs this solved to ship its own product. This grant is about building it properly and releasing it as a public good.
The grant deliverable is a two-part open-source framework, plus the reference workflow applications needed to demonstrate it against realistic financial use cases.
The core of the grant. A scenario-based testing framework that lets any Canton team define workflow test cases and run them automatically against Canton Sandbox. Test suites cover correct-path execution, policy violation rejection, unauthorised controller access attempts, replay attacks on completed workflows, and edge cases at security-relevant boundaries (spend limits, velocity thresholds, counterparty allowlists, time window expiry). The harness returns structured, machine-readable PASS/FAIL results with diagnostic output, suitable as input for change-control documentation, security review evidence packs, and regulatory audit workflows.
A thin configuration adaptor that connects the test harness to whichever identity or guardrail standard the operator has deployed, whether Tenzro’s identity components, an emerging Canton KYA CIP, or a custom enterprise implementation. This is what makes the harness portable across different Canton deployments rather than tied to Sigli’s specific setup.
To demonstrate the harness against realistic conditions, we are building a reference DAML workflow implementation: a standardised multi-step workflow pattern with precondition validation, conditional branching, human override, and on-ledger audit trail. This is the subject matter against which the test harness runs. The reference workflow is open-sourced alongside the harness as a usable scaffold for any Canton team.
-- WorkflowAction, WorkflowContext, PolicyConfig, checkPolicy, and
-- executeAction are defined in companion modules (Types.daml, Policy.daml)
data WorkflowStatus = Pending | Running | Paused | Completed | Failed
deriving (Eq, Show)
data WorkflowStep = WorkflowStep
with
stepId : Text
description : Text
action : WorkflowAction -- Tagged sum: Allocate | Settle | Monitor | etc.
deriving (Eq, Show)
template WorkflowAgent
with
operator : Party
workflowId : Text
steps : [WorkflowStep]
currentStep : Int
policyRef : ContractId PolicyConfig
status : WorkflowStatus
where
signatory operator
choice AdvanceStep : ContractId WorkflowAgent
with context : WorkflowContext
controller operator
do
assertMsg "Workflow is not in Running state" (status == Running)
let step = steps !! currentStep
policy <- fetch policyRef
assertMsg "Policy violation" (checkPolicy policy context)
executeAction step.action context
create this with
currentStep = currentStep + 1
status = if currentStep + 1 >= length steps
then Completed else Running
choice PauseWorkflow : ContractId WorkflowAgent
controller operator
do create this with status = Paused
choice AbortWorkflow : ()
controller operator
do return ()
Key design decisions:
-- ScenarioStep, ScenarioResult, WorkflowStatus, executeStep, and diagnostics
-- are defined in companion modules (Types.daml, ScenarioRunner.daml)
template WorkflowScenario
with
testRunner : Party
scenarioId : Text
steps : [ScenarioStep]
expectedOutcome : WorkflowStatus
where
signatory testRunner
choice RunScenario : ScenarioResult
controller testRunner
do
results <- mapA executeStep steps
let allPassed = not (null results) && all (.passed) results
return ScenarioResult with
scenarioId
passed = allPassed && (last results).workflowStatus == expectedOutcome
stepResults = results
summary = if allPassed then "PASS" else "FAIL: " <> diagnostics results
Scenario coverage:
Output format: the harness produces structured results at two levels:
This means a developer seeing a failure knows which scenario failed and at which step, without reading raw Sandbox logs. The output is structured JSON, consumable programmatically or passed into a team’s own reporting tooling. Passing suites include a summary with scenario IDs and timestamps, giving auditors a clear record of what was tested and when.
A thin adaptor that translates workflow constraints into calls to whichever identity or guardrail primitive the operator has deployed. In practice, for Sigli’s own deployments this means connecting to Tenzro’s identity and wallet components. For other Canton teams it means connecting to AgenticLedger, an emerging Canton KYA CIP, or a custom implementation.
Interoperability across different implementations: Different identity and guardrail implementations can have meaningfully different enforcement semantics. One may reject a policy violation by returning an error code; another may archive a contract and emit an event; a third may require a supervisor’s countersignature before a step can proceed. The PolicyConfig layer handles this by defining a standard interface that each adaptor must satisfy, and by making the enforcement outcome explicit in scenario test output, so a team can verify not just that a violation was rejected, but that it was rejected in the way their compliance framework requires. A team migrating from one identity implementation to another can rerun their existing scenario suite against the new adaptor and compare enforcement behaviour directly, without rewriting tests.
The adaptor ships with a reference implementation against a generic Canton KYA interface. Custom adaptors for other identity and guardrail implementations follow a documented pattern and can be contributed back to the repository.
The harness ships with three scenario test suites written against realistic financial workflow examples. The test suites are the grant deliverable. The example workflows they run against are open-sourced as reference scaffolding for any Canton team to use.
Each test suite produces the structured, exportable output described above, demonstrating that the harness works across qualitatively different workflow types, not just a single curated case.
A Canton team with existing DAML contracts can integrate the harness in three steps:
The PolicyConfig adaptor connects to the team’s existing identity and guardrail implementation. A reference adaptor against a generic Canton KYA interface is included. Teams using a custom implementation follow a documented adaptor pattern, typically a few hours of work.
The intent is that a team already running Canton Sandbox can go from zero to a running scenario suite in under a day. The reference suites and annotated documentation are designed specifically around this goal.
The DAWE is designed around the assumption that off-chain components are not fully trusted, and that the Canton ledger is the authoritative security boundary.
| Threat | Mitigation |
|---|---|
| Compromised off-chain orchestrator | Policy enforcement is on-ledger via PolicyConfig. A compromised automation process cannot advance a workflow step that violates policy. The Canton ledger rejects the transaction unconditionally. |
| Unauthorised controller access | DAML’s signatory model ensures only the designated operator party can exercise workflow choices. The scenario test suite includes explicit adversarial cases covering this. |
| Policy bypass via malformed input | The test harness systematically covers malformed inputs, type boundary conditions, and out-of-range values as named scenario classes. |
| Replay attacks on completed workflows | Completed workflow contracts are archived. Archived contracts cannot be re-exercised. Settlement reference implementation includes explicit replay scenario tests. |
| Controller key compromise | PauseWorkflow and AbortWorkflow provide immediate circuit-breaker control. HSM key management and rotation guidance is included in the mainnet readiness guide. Tenzro’s MPC wallet architecture (threshold-signed, no single key) further mitigates key compromise risk for Sigli’s own deployments. |
| Test environment contamination | The test harness runs exclusively against Canton Sandbox with dedicated test parties, architecturally isolated from production ledger state. Scenario contracts are archived on completion. |
| SDK or CIP upgrade introduces regression | The scenario suite is designed as a regression suite, re-runnable after any SDK or CIP change. Output is structured for change-control documentation. |
Sigli is building the DAWE test harness because we need it to ship our own product. Every financial workflow in Sigli’s neobank, yield allocation, settlement chains, treasury rebalancing, and compliance monitoring, will be verified against the harness before mainnet deployment. The security evidence the harness produces is what we use to satisfy enterprise customers’ procurement and audit requirements.
The grant scope is the open-source test harness and the reference scenarios that make it usable by other teams.
The commercial advantage Sigli is building is in the hosted infrastructure, managed compliance services, and enterprise SLAs that Canton institutions will pay for. Open-sourcing the test harness does not give that away. It establishes Sigli as a Canton contributor and creates the ecosystem adoption of the testing standard that the managed product sits on top of.
Stripe, Twilio, and HashiCorp built durable businesses on the same model: open-source the infrastructure, commercialise the managed layer. The DAWE is Sigli’s infrastructure contribution to Canton. The neobank is the product.
Institutional and enterprise teams The primary audience is an enterprise development team or systems integrator building on behalf of a bank, asset manager, or financial infrastructure provider. These teams need both workflow automation and reproducible security verification evidence for internal sign-off.
Initial pilot targets: we have identified three categories of early adopter we intend to approach directly after Milestone 1:
Distribution through Canton’s enterprise developer channels, direct outreach to the above, and co-presentation with the Foundation at enterprise events.
AgenticLedger integration AgenticLedger handles agent creation and orchestration. The DAWE handles workflow security testing. The two are complementary. We will propose a formal integration, positioning the DAWE as the standard verification runtime for any AgenticLedger agent driving multi-step DAML workflows.
RWA issuers via treasury test suite The treasury rebalancing test suite is a direct starting point for RWA issuers running manual treasury operations on Canton. We will present it as a free, ready-to-run scenario suite covering the most common security boundaries these teams need to demonstrate to auditors and risk committees, removing weeks of bespoke preparation from their deployment timeline.
Foundation asks Introductions to engineering and security leads at two to three active RWA issuers, and a slot at one Canton developer office hour or enterprise-facing community event to demonstrate the harness and its security verification output. We handle all follow-up independently.
Positioning the DAWE as a community standard requires more than open-sourcing code. We are approaching it in three stages:
Other teams are building identity, wallet, and KYA primitives. Sigli is using those and Tenzro’s infrastructure where they fit, not competing with them. The DAWE addresses a distinct and currently unaddressed gap: automated security verification and regression testing for DAML applications. This is the layer that makes the underlying primitives safely deployable in real enterprise environments.
| Identity / Wallet / KYA proposals | Tenzro components | DAML Automated Workflow Evaluator (DAWE) | |
|---|---|---|---|
| What it builds | On-chain financial primitives | Agent identity, MPC wallets, payment stack, settlement | Automated security and QA testing framework for DAML workflows |
| Sigli’s relationship | Building on top | Using as infrastructure where applicable | Building and open-sourcing for production use |
| Who else benefits | Canton developers broadly | Tenzro ecosystem developers | Any Canton team deploying DAML contracts in an enterprise context |
| What it unlocks for enterprise | Necessary foundation | Custody, payments, settlement | Security review evidence, audit documentation, governance sign-off |
The project will be delivered in two phases over 16 weeks.
Deliverables:
Acceptance Criteria:
Deliverables:
Acceptance Criteria:
We will run the regression test suite within 14 days of any major DAML SDK release and publish a compatibility report. When Canton identity or wallet CIPs are ratified, we will update the PolicyConfig integration hooks within 30 days. The GitHub repository will maintain a public triage process with a 10-day response SLA on bug reports and prompt response to security disclosures.
Sigli’s commercial roadmap builds directly on this foundation: hosted workflow automation, managed compliance monitoring, and enterprise SLAs for Canton institutions. The open-source harness remains community-owned. The commercial layer sustains long-term upstream contribution.
Fully additive. No changes to the Canton core protocol, consensus layer, or any existing application contract.
All code released under the MIT License.
Adoption metrics we will track and report:
| Metric | 3-month target |
|---|---|
| Canton teams using the harness | 2 pilot teams |
| DAML workflows tested with the harness | 3 (reference suite) |
| Security scenario suites run | 3 reference + pilot runs |
| GitHub stars/forks | 5 |
These metrics will be published within a 3-month window or as soon as achieved.
Total: 337,000 CC (~$50,000 USD)
| Milestone | Payment | Timing |
|---|---|---|
| M1 | 168,500 CC | On acceptance of Milestone 1 |
| M2 | 168,500 CC | On acceptance of Milestone 2 |
Volatility stipulation: Project duration is approximately 16 weeks. The CC amount is fixed regardless of CC/USD exchange rate movements.
Sigli.ai is building the neobank for AI agents on Canton, with enterprise institutions as the primary customer. For the foundational infrastructure, we are building on what already exists: Tenzro’s agent identity, MPC wallets, payment stack, and settlement infrastructure where applicable, and Canton’s emerging community standards for everything else.
The one gap we are filling is the automated security verification and testing layer for DAML applications. That is what the DAWE is. It is not an attempt to rebuild the stack. It is the specific piece of infrastructure that is missing and that every Canton team building for enterprise clients will need.
The test harness is something we are building because we cannot ship Sigli’s neobank to enterprise clients without it. The grant covers the open-source release and the reference scenarios that make it immediately usable by other Canton teams. The neobank is the product. The harness is the ecosystem contribution. Canton is where both live.
SIG: daml-tooling
Rebuilt from the recorded board moves (complete history). get_dev_fund_lifecycle(number) gives the same in the MCP.