CoreGuardCoreGuard

Engineering developments · audited 12 November 2026

Every advancement. Every source. Every honest limit.

A detailed English record of what has shipped across Stellar, Core DAO and Pi Network — and what remains DRY_RUN, gated, unfunded or open for contribution.

Official product catalogDDE SDK live referenceRepository issue trackerCanonical repository status
01 · STELLAR
Mainnet evidence, PSAR/1, DEX and ESCROW/1
02 · CORE DAO
Registry hardening, replay and DDE/1
03 · PI NETWORK
Payment, wallet and anchor plans — DRY_RUN

Stellar · mainnet evidence plus new executable surfaces

Stellar developments

New code is separated from external adoption: a merged example is not a named production DEX integration, a JS escrow mirror is not an on-chain contract, and a release workflow is not an npm publication.

BUILT · TEST_EXECUTED · INTEGRATION NOT_BUILT

PSAR/1 — Pre-Sign Authorization Receipt

A wallet can re-verify an authorization receipt before signing and return PASS, BLOCK for tampering, or BLOCK for expiry.

  • The receipt is bound to the exact unsigned transaction bytes. A changed byte fails closed instead of being signed.
  • The current catalog records 37 tests. PSAR/1 v1 does not semantically decode XDR content; that deeper check is reserved for PSAR/2.
  • The Freighter integration is a proposal, not a shipped wallet integration. No external wallet adoption is claimed.
PSAR/1 sourceOffline demoFreighter proposal
DELIVERED · TESTNET/OFFLINE VERIFIED

Stellar DEX integration example

Issue #26 is closed as completed: a community contribution added a runnable Soroban DEX integration example with DEX-GATE/1 and DDE/1.

  • The example combines preflight swap gating, a cryptographic execution receipt, bilateral escrow release, a Soroban commitment plan and an offline verifier.
  • The delivery records a 5/5 adversarial suite and bilingual documentation. It was merged through PR #51 on 11 November 2026.
  • This is a reusable testnet/offline example, not a claimed Soroswap, Aquarius or Phoenix production deployment. The contribution has no approved bounty funding.
Integration exampleOffline verifierIssue #26 · completed
SHIPPED JS MIRROR · DRY_RUN · NOT LAUNCHED

ESCROW/1 — bounty escrow mirror

The CG-BTY-007 lifecycle now has an executable JavaScript mirror for fund, claim, deliver, verify, release and refund.

  • Verify-before-release, digest-bound maintainer signatures, a locked contributor, single-spend release and full-funder refund are enforced with negative controls.
  • Issue #55 records a 15-test integration suite. The mirror contains no Soroban deployment, XDR, RPC or network call and moves no funds in DRY_RUN.
  • The on-chain bounty contract remains an open proposal. Reward funding, external human review and owner broadcast authorization are not completed.
ESCROW/1 source15-test suiteIssue #55 · on-chain proposal
SOURCE SHIPPED · NEW MAINNET INSTANCE OWNER-GATED

Soroban authorized lane and Phase 5 deploy evidence

The commitment-anchor source adds commit_authorized with owner.require_auth() and in-contract identifier derivation.

  • Phase 5 evidence records create ledger 65,408,001 and exact balance arithmetic. Fresh-vault readback is SIMULATED_NONE and the saved deploy verdict remains NOT_CONFIRMED.
  • The existing CCKA…MXPSP mainnet instance remains the deployed/1 binary. Issue #24 stays open for a separate owner decision to deploy a new authorized-lane instance.
  • The rejected first attempt is preserved as fail-closed evidence rather than hidden or rewritten as a success.
Anchor contractPhase 5 evidenceIssue #24 · owner decision
INTERNAL RFC · NOT SUBMITTED

Fail-closed receipt semantics — SEP draft

Issue #56 proposes one shared Stellar vocabulary: VERIFIED, MISMATCH, or UNKNOWN with a named reason.

  • No chain authority means UNKNOWN, not success. Contradictory authority evidence means MISMATCH. UNKNOWN must never render as a checkmark.
  • The draft points to the existing verifier and live Soroban commitment anchor as reference implementation evidence.
  • It is an internal draft for review. No SEP submission or ecosystem acceptance is claimed.
Draft semanticsIssue #56 · RFC
DOUBLE-GATED · NOT PUBLISHED

@coreguard/stellar npm publication

The Stellar package and its 13-package dependency closure have local publish checks and a provenance-enabled release workflow.

  • The package includes the guard closure, DEX gating, Soroban helpers, Freighter wrapper and credential-gated mainnet runner.
  • NPM_TOKEN configuration and explicit owner approval are still pending. Local source installation must not be presented as a public npm release.
Stellar packageIssue #25 · release tracking
Open the complete Stellar evidence page

Core DAO · live anchor, stronger tests and shared application gates

Core DAO developments

The live Core registry is distinct from newer V3 source, DRY_RUN replay packages and application-level DDE/1 tooling. Each link opens the exact contract, test, package or live reference behind the claim.

LIVE · CHAINID 1116 · READ-ONLY VERIFICATION

EvidenceRegistry — live Core mainnet anchor

CoreGuard's Core anchor stores commitments rather than custodying assets or depending on an oracle.

  • The registry 0x037dF08F2d43c5D03759279Fe35664f6AFf9EA6E and the recorded agent execution remain independently inspectable on Core Scan.
  • The V3 source family adds explicit intent binding, flat-fee accounting, signature and deadline controls. A source improvement is not presented as a new mainnet deployment.
Registry sourceV3 sourceLive registry on Core Scan
SHIPPED · FOUNDRY 43/43

EvidenceRegistryV3 invariant and fuzz hardening

Stateful invariants and fuzz tests exercise the registry across sequences of calls rather than only single happy-path transactions.

  • The suite checks treasury accounting, immutable intents, intent-bound anchors, domain/version pinning, exact fees, expiry, signature binding and singleton identifiers.
  • These are contract tests in the repository. They strengthen reviewability but are not a third-party security audit.
Invariant and fuzz suiteV3 contract tests
DRY_RUN · INTEGRATION NOT_BUILT

COREDao-KILLER/1 replay and agent gate

The Core-focused package wraps agent-payment and universal-DApp decisions with deterministic replay and fail-closed outcomes.

  • coreGate returns SUBMIT only for VERIFIED, BLOCK for REJECTED and HOLD for unknown outcomes. coreAnchor returns a plan with submit:false and mode:DRY_RUN.
  • The package status explicitly reports no credentials, no authorization and no execution. BTCFi vault or strategy integrations are not claimed as live.
COREDao-KILLER/1 sourceFeature and status document
SHIPPED SDK · NOT A CHAIN DEPLOYMENT

DDE/1 SDK release gate for Core DApps

verifyFixture and releaseWhen turn delivery evidence into explicit HOLD, RELEASE or REFUSED decisions for applications that integrate the SDK.

  • RELEASE requires a VERIFIED report and the integrator's acceptance predicate. A REJECTED report is refused even when the predicate returns true.
  • The four-scenario reference covers an honest HOLD, accepted RELEASE, one-flipped-byte REFUSED and a forced-true predicate that is still REFUSED.
  • The SDK never signs, broadcasts or decides delivery conformity itself. Payment settlement never implies delivery acceptance.
DDE SDK sourceLive four-scenario referenceSDK page contract tests
DRY_RUN · CROSS-CHAIN INTEGRATION OPEN

TRINITY/1 — Core, Stellar and Pi coordination

The trinity package defines one execution-truth model across the three ecosystems without upgrading a plan into a live bridge.

  • Issue #34 tracks dual receipts, correlated commitments and source/destination evidence linking. Cross-chain correlation must never turn UNKNOWN into VERIFIED.
  • Core and Stellar each have live anchor evidence; the cross-network bridge itself and every Pi lane remain DRY_RUN or PLAN_ONLY.
TRINITY/1 sourceTrinity statusIssue #34 · cross-network track
Open Core DAO services

Pi Network · explicit plans, no inflated launch claim

Pi Network developments

The upstream package defines payment, commerce, wallet, DApp and commitment-anchor boundaries, but its own status remains DRY_RUN and INTEGRATION NOT_BUILT. No Pi mainnet execution or three-network bridge is claimed.

DRY_RUN · INTEGRATION NOT_BUILT

PI-NETWORK/1 payment and commerce flow

The repository contains Pi payment and commerce planning functions for Pi Browser, Pi Wallet and Pi DApps.

  • Payment plans return submit:false and mode:DRY_RUN. Execution requires the Pi SDK and Pi Browser; the module reports no credentials, authorization or execution.
  • No Pi mainnet payment is asserted by this source. The website's own Pi application flow is separate from this upstream package status.
PI-NETWORK/1 sourcePi SDK helpers
PLAN ONLY · NO BROADCAST

Pi commitment anchor, DApp shield and wallet connect

Commitment anchoring and wallet/DApp helpers define the intended integration boundary while keeping every network action unsubmitted.

  • piCommitmentAnchor returns a transaction plan with submit:false and DRY_RUN. Missing identifiers remain HELD.
  • The upstream PRODUCTS catalog did not add a new Pi product surface in this update. Existing Pi concepts stay DRY_RUN or PLAN_ONLY until committed evidence ships.
Implementation boundariesPi seven-rung plan
OPEN DESIGN TRACK · PI DRY_RUN

Core ↔ Stellar ↔ Pi evidence linking

Issue #34 is the canonical track for future bridge and anchor integrations across the three networks.

  • Planned deliverables include an integration RFC, runnable offline examples, per-network evidence rows and partner-facing notes.
  • There is no live Pi anchor or completed three-network bridge claim. Any future receipt must retain its actual per-chain verification level.
Issue #34 · design trackTRINITY/1 status
Open the Pi Network page
Repository issues · bodies and latest relevant comments reviewed

Important open tracks — not finished products

These issues matter because they define the next wallet, agent, RWA, reviewer, security and release work. They are shown as open scope, with absent deliverables and funding limits kept visible.

OPEN CALL · NOT BUILT

#57 · Wallet-side receipt verify widget

A proposed framework-free wallet renderer would show VERIFIED, MISMATCH and UNKNOWN before approval, with tests that make tampered evidence impossible to render as a pass.

  • No wallet adoption is promised. The requested packages/verify-widget surface is not present in the audited repository tree.
Review issue #57
OPEN CALL · NO ISSUER ENGAGED

#58 · Evidence passports for RWA issuance

A proposed issuance profile would map the existing evidence-passport-v2 model to authorization, execution records, commitments and fail-closed verdicts.

  • The generic passport model exists; the RWA profile and worked synthetic specimen remain contribution scope. No RWA issuer, anchor or funding is claimed.
Passport v2 modelReview issue #58
OPEN CALL · KIT NOT BUILT

#59 · Agent trust integration kit

The proposed kit would combine the agent payment gate, X402/1, budget limits and offline receipt verification into an agent-framework quickstart.

  • Building blocks exist, but the requested quickstart, policy cookbook and end-to-end example remain open scope. No agent framework is engaged.
X402/1 sourceReview issue #59
OPEN · EXTERNAL WALLET NOT INTEGRATED

#27 · Stellar wallet integration example

The wallet track calls for a runnable Freighter, Lobstr, Rabet, Albedo or xBull example with pre-sign authorization, post-execution verification and an offline runner.

  • The Freighter wrapper and PSAR proposal exist, but the full external wallet example remains open. This is distinct from the completed DEX example in #26.
Freighter wrapperReview issue #27
OPEN · UNFUNDED

#28 · Independent reviewer kit

The proposed kit would document five verification runners and add byte-flip and missing-evidence controls for independent review.

  • The latest issue discussion keeps CG-BTY-003 open and unfunded; the contributor chose to wait for approved funding. The proposed REVIEWER-KIT.md is not present in the audited tree.
Existing evaluation guideReview issue #28
OPEN · THIRD-PARTY AUDIT NOT PERFORMED

#30 · Security review and audit preparation

The review track covers the Soroban anchor, verifier semantics, canonicalization, fail-closed boundaries, credentials and reproducibility.

  • Repository self-reviews and test evidence do not equal an independent audit. No completed third-party audit is claimed.
PSAR self-reviewReview issue #30
OPEN · RELEASE GATES REMAIN

#32 · CI, release and supply-chain hardening

This track keeps npm publication double-gated and covers deterministic CI, provenance, dependency review, least-privilege permissions and reproducible verification.

  • A prepared workflow is not a published package. Token configuration, owner approval and the remaining hardening checklist stay explicit.
CLI sourceReview issue #32

VERIFIED ≠ SAFE. Execution evidence proves a defined authorization relationship; it does not certify that a protocol is risk-free. No customer, partner, revenue, funding award or third-party audit is implied by this development log.

Browse all products