Validating Conditions
Before you ship a condition — or before you ask the network to evaluate one — validate it locally. Client-side validation catches the overwhelming majority of mistakes (typos, wrong field names, missing required properties, illegal nesting depth, comparator typos) without ever touching a node.
You have two options. Pick whichever fits your stack — they overlap heavily.
JSON Schema validator (any language)
You want zero TACo dependencies, you are validating in CI, or you want inline editor validation via $schema. See Building Conditions with an LLM → JSON Schema integration.
validate-conditions.ts (this page)
You are already in TypeScript, or you need the SDK's runtime semantics (e.g. nesting-depth checks that JSON Schema cannot express).
This page gives you a 40-line TypeScript script you can drop into any project.
The script
Save this as validate-conditions.ts:
#!/usr/bin/env npx tsx
/**
* Validates conditions.json against the TACo SDK schemas.
* Catches client-side validation errors before they hit the network.
*/
import { conditions } from '@nucypher/taco';
import * as fs from 'fs';
import * as path from 'path';
async function main() {
const conditionsPath = path.join(__dirname, '..', 'conditions.json');
console.log(`Loading conditions from: ${conditionsPath}`);
const conditionsJson = fs.readFileSync(conditionsPath, 'utf-8');
const conditionsObj = JSON.parse(conditionsJson);
console.log('\nConditions loaded:');
console.log(JSON.stringify(conditionsObj, null, 2));
console.log('\n--- Validating with TACo SDK ---\n');
try {
const expr = conditions.conditionExpr.ConditionExpression.fromObj(conditionsObj);
console.log('✅ Conditions are VALID according to TACo SDK!');
console.log('\nParsed condition type:', expr.condition.conditionType);
} catch (error) {
console.error('❌ Conditions are INVALID according to TACo SDK!');
const errorStr = error instanceof Error
? `${error.name}: ${error.message}\n\nStack: ${error.stack}`
: JSON.stringify(error, null, 2);
const errorPath = path.join(__dirname, 'validation-error.txt');
fs.writeFileSync(errorPath, errorStr);
console.error(`\nFull error written to: ${errorPath}`);
console.error('\nError message:', error instanceof Error ? error.message : String(error));
process.exit(1);
}
}
main().catch(console.error);Setup
Place your condition in conditions.json at the project root (or adjust the path inside the script).
Run it
Valid output
Invalid output
The full Zod error (with stack) is written to validation-error.txt so you can paste it into an LLM verbatim — see Building Conditions with an LLM and Troubleshooting.
What this catches
Unknown / misspelled
conditionTypevaluesMissing required fields (
returnValueTest,chain,parameters, …)Wrong literal values (
"AND"instead of"and","=="written as"=")MultiCondition nesting deeper than the allowed limit (4 levels total across
CompoundCondition,IfThenElseCondition, andSequentialCondition)Compound condition with more than 5 operands
Sequential condition with fewer than 2 or more than 20 variables
Context variable names that violate the
/^:[a-zA-Z_][a-zA-Z0-9_]*$/patternABI validation referencing parameter indices that do not exist on the declared function signature
Invalid hex strings for verifying keys, contract addresses, bytecode hashes
What this does not catch
Client-side validation only checks shape. It cannot tell you:
Whether the contract at
contractAddressactually exists or has the function you declaredWhether the JSON API endpoint will return data in the shape your JSONPath expects
Whether the user will satisfy the condition at decryption time
For end-to-end testing, run the condition against a local testnet (see Quickstart) or your own integration.
Source
The canonical copy of this script lives at nucypher/taco-web/packages/taco/scripts/validate-conditions.ts.
Last updated