No Ward custody
No wallet storage, no secret handling, and no delegation of signing authority to Ward.
Ward Conformance
A clean institutional standard for default-resolution integrity.
Ward Conformance is the institutional assurance layer for deterministic default resolution. It means a credit product resolves claims through explicit on-ledger checks, preserves the signer boundary, and produces a record partners can review without trusting Ward as a discretionary operator.
9 on-ledger checksUnsigned settlement instructionsReviewable conformance receiptJune 2026 hardening complete
Core invariant
ward_signed = False — always.
Ward prepares deterministic validation results and unsigned settlement instructions. Institutions sign. The chain settles. Ward never holds private keys, never acts as custodian, and never becomes a transaction signatory.
No Ward signature
Unsigned packets are prepared for institutional review and execution by the responsible counterparty.
Clean institutional boundary
Teams can confirm exactly where Ward stops and institutional authority begins.
What conformance means
Conformance is a technical claim about process integrity.
A Ward-conformant product is not being described as risk-free or approved by a regulator. It is being described as technically disciplined: the default path is deterministic, the evidence is on ledger, and the signing boundary remains with the institution.
Deterministic evidence standard
Ward Conformance means default resolution is driven by explicit on-ledger evidence gates every time, not by operator discretion, hidden policy logic, or off-chain judgment.
Preserved institutional boundary
A conformant integration keeps signing authority with the institution, vault operator, or designated counterparty. Ward validates, prepares, and reports, but does not sign or settle.
Reviewable by serious partners
The resulting conformance record is designed for engineering, risk, compliance, and capital review. It is a technical assurance surface, not a marketing promise.
On-ledger evidence gates
The nine checks every conformant default path must satisfy.
These checks make the decision path inspectable. They are designed to show not just that a claim was accepted or rejected, but which ledger facts justified the outcome.
| Step | Check | Ledger evidence | Why it matters |
|---|---|---|---|
| 01 | Policy artifact exists and matches Ward taxon rules | XLS-20 policy NFT exists and carries the expected Ward policy taxon. | Prevents forged or misclassified policy references from entering the claim path. |
| 02 | Coverage window is valid on ledger time | XRPL ledger close_time and matching premium payment remain inside policy terms. | Removes server-clock discretion and proves coverage was active when the claim was filed. |
| 03 | Vault binding is correct | Policy metadata vault reference matches the defaulted vault under review. | Stops a valid policy from being redirected to an unrelated loss event. |
| 04 | Default signal is confirmed from authoritative state | Ward re-reads LedgerEntry(index=loan_id) and confirms the LSF_LOAN_DEFAULT flag. | Treats event streams as hints, not authority, and anchors the decision to final ledger state. |
| 05 | Loss amount is real and bounded | Vault loss is greater than zero drops before any payout can be prepared. | Prevents zero-loss or malformed claims from moving into settlement construction. |
| 06 | Coverage pool remains solvent | Pool usable balance, net of XRPL reserve requirements, is sufficient for the claim. | Confirms the pool can support the payout without violating reserve or balance constraints. |
| 07 | Policy is still live | The policy NFT has not already been burned, settled, or invalidated. | Provides replay protection and blocks duplicate or already-closed claims. |
| 08 | Claimant ownership is proven on ledger | AccountNFTs(account=claimant) confirms the claimant still holds the policy NFT. | Ensures the filing party is the party entitled to invoke the policy. |
| 09 | Solvency and signer boundary both hold at settlement | Pool solvency thresholds and rate limits pass, and Ward returns unsigned settlement instructions only. | Stops pool drainage and preserves the institutional requirement that Ward never signs. |
June 2026 security hardening sprint
Security maturity was tightened before institutional outreach scaled.
The June 2026 sprint focused on closing audit findings, removing unsafe assumptions, and hardening the protocol surface for institutional review. The result was v0.2.10, a stricter implementation of the same conformance model.
18 audit findings resolved
The June 2026 Aikido SAST/SCA rescan surfaced 18 findings. All critical and high-severity issues were remediated in-sprint. Full report: wardprotocol.org/reports/Ward_Protocol_Security_Report_June2026.pdf
Fail-closed controls
Authentication, premium verification, and unsafe production defaults were hardened so invalid states fail closed instead of being quietly accepted.
Signer-boundary enforcement
ward_signed = False was enforced repo-wide so unsigned transaction construction replaced signing paths across the protocol surface.
Operational hardening
Redis-backed rate limiting, settlement locking, SSRF protections, validation tightening, and better rejection reporting reduced operational risk.
Pilot readiness timetable
Four visible phases from technical review to production certification.
01
Self-serve conformance review
Expose the specification, demo workspace, SDK/API surfaces, and receipt model so partners can review Ward without a guided sales call.
Now
02
XRPL/XLS-66 pilot lane
Use the XRPL Altnet path for wallet validation, policy NFT evidence, 3-ledger confirmation, and unsigned settlement review.
30-60 days
03
Cross-chain testnet proof pack
Package Flare, XRPL EVM, XDC, Polygon, Stellar, Algorand, and Solana testnet artifacts into partner-reviewable receipts.
60-120 days
04
Production readiness and certification
Pair the third-party audit path with pilot receipts, mainnet branch readiness, and the public conformance registry.
Mainnet trigger
Verification for partners and institutions
Conformance should be verifiable, not merely asserted.
01
Review the standard
Compare the product workflow against the Ward specification and verify that the same nine on-ledger checks govern default resolution.
02
Inspect the evidence path
Confirm that each claim outcome is tied back to authoritative ledger state, not server clocks, mutable dashboards, or discretionary approvals.
03
Confirm the signer boundary
Check that settlement artifacts are unsigned when produced by Ward and that institutional wallets, not Ward, remain the signing authority.
04
Validate the receipt
Review the conformance receipt or reproduce the same checks against your own node, RPC provider, or internal validation environment.