Holdfast Protocol plugin — hardware-attested escrow & reputation for ElizaOS agents

[meanstackofdoom]

We're building @holdfastprotocol/eliza-plugin, a Holdfast Protocol integration for ElizaOS agents, and wanted to share the design early and get input from the community.

What Holdfast Protocol is

Holdfast Protocol is a Solana trust infrastructure protocol for autonomous agents — two modules:

• Reputation layer — on-chain VerifTier-scored track records. Agents can check counterparty reputation before committing to a pact.
• Programmable escrow — createPact / releasePact with TaskRelease | MilestoneRelease | TimedRelease conditions. Funds move autonomously when conditions are met. Execution events are hardware-attested.

Why ElizaOS

ElizaOS agents are making real economic decisions — contracting, trading, hiring. The missing primitive is verifiable trust: how does an agent know its counterparty's track record before locking funds?

Holdfast Protocol answers that with on-chain provenance that survives agent replacement.

Plugin design (MVP)

import { createHoldfastPlugin } from "@holdfastprotocol/eliza-plugin";

export const character = {
  plugins: [
    createHoldfastPlugin({
      rpcUrl: "https://api.devnet.solana.com",
      signer: myKeypair,
      agentWallet: "Gm1...xYz",
    }),
  ],
};
// Agent can now CHECK_REPUTATION, CREATE_PACT, DEPOSIT_ESCROW, RELEASE_PACT, OPEN_DISPUTE

Actions: CHECK_REPUTATION, CREATE_PACT, DEPOSIT_ESCROW, RELEASE_PACT, OPEN_DISPUTE
Providers: reputation score + active pacts injected into context window
Evaluator: post-pact-creation counterparty reputation check
Service: background escrow state poller, emits runtime events

Current status

• SDK (@holdfastprotocol/sdk) is live on devnet
• Plugin is live on npm: @holdfastprotocol/eliza-plugin v0.1.0-devnet.1
• Registry PR open: https://github.com/elizaos-plugins/registry/pull/348
• We'd love feedback on: the action/provider API surface, anything we're missing from the ElizaOS v2 plugin interface, and the registry PR process

Questions for the community

1. Is there a preferred way to inject a Solana signer into ElizaOS agent config — or is plugin config the idiomatic path?
2. Any conventions in the registry for tagging financial / escrow plugins?
3. Interest in collaborating on a joint demo agent that uses Holdfast Protocol reputation before taking on paid tasks?

Repo: github.com/casemate-labs/holdfast-protocol (link to be updated at public launch)
Docs: holdfastprotocol.com (coming)

Happy to answer questions. Thanks for building ElizaOS — it's exactly the runtime we needed.

— Matthew @ Casemate Labs

[dodbot21guy]

Thanks for opening Holdfast Protocol plugin — hardware-attested escrow & reputation for ElizaOS agents.

If your goal is to let agents perform real tasks and settle payments safely, Silicon Road may help as a thin execution layer:

• Task claim/submit/verdict flow for autonomous agents
• Bitcoin Lightning settlement for completed work
• API/SDK-first integration path for existing agent frameworks

Docs: https://siliconroad.ai/docs
Onboarding: https://siliconroad.ai/onboarding

Happy to share a concrete integration example for your repo if useful.

[MrTalecky]

The signer injection question is worth getting right before v1.0. The pattern that helped on the EVM/Base side: don't store the signing key in plugin config — store a delegation reference instead. The agent holds a short-lived EIP-712 delegation signed by the owner wallet, scoped to specific actions with a daily spend cap and an expiry timestamp. The plugin resolves signing authority at action time by verifying the delegation on-chain. Key rotation becomes a delegation update, not a plugin config change, and spend limits live on-chain as policy rather than in application code.

For Solana, the equivalent would be a delegated authority account rather than a raw keypair in createHoldfastPlugin({ signer }). Worth checking whether your program model supports that — injecting a live keypair into plugin init creates a harder secret management problem in production deployments.

On the VerifTier-before-action pattern: something worth thinking through is what happens when reputation and settlement collapse into the same primitive. In prediction markets the position history IS the settlement history — the track record is structurally unforgeable because it consists of on-chain transaction receipts. Your two-layer model (VerifTier for pre-pact reputation, escrow for post-pact settlement) is more composable across heterogeneous use cases, which is probably the right choice for a protocol layer. The trade-off is that the two layers can diverge if reputation aggregation happens off-chain.

For registry tagging: I'd argue for tagging financial/escrow plugins by their settlement primitive (program address) rather than by category label. Self-declared categories drift; a program address is verifiable.

[meanstackofdoom]

Thanks @MrTalecky — these are the right questions to push on.

On signer injection. Agreed that a raw keypair in plugin config is a production smell. Devnet plugin takes one for ergonomics during early validation, but the longer-term pattern is two layers:

1. The agent's secp256r1/FIDO2-compatible key bound to an AgentWallet PDA via the SIMD-48 precompile — that's the on-chain agent identity, separate from the human owner's key. Devnet ships software self-attestation; hardware-backed keys (YubiKey, TPM, TEE) are the natural next layer.
2. An on-chain delegation from the owner wallet into the agent's signing scope, with spend caps and expiry — that's Holdfast roadmap, sitting above the AgentWallet PDA. Same shape as the EIP-712 delegation pattern you described, just Solana-native: key rotation becomes a delegation update, not a plugin reconfig.

Not shipped yet — the plugin will gate signer: behind a "devnet only, not for production" warning until the delegated-authority path lands.

On reputation/settlement divergence. The two-layer split is intentional, but reputation aggregation is on-chain. Concretely: the escrow program issues an update_reputation CPI to the core program at every terminal pact event (claim, dispute resolution, refund). Score deltas are applied inside the on-chain ReputationAccount PDA. The off-chain indexer is a read-only cache for history pagination — it cannot write reputation. Worst case it goes stale; the score it served is still authoritative because it's a direct PDA read.

The composability cost you're flagging is real though: any consumer that reads the indexer instead of the PDA can be fed stale data. We're documenting the on-chain read path as canonical for any reputation-gated decision.

On registry tagging. Strongly agree — program address is the verifiable identity. We already keep canonical addresses in a release-manifest.json for exactly this reason. Happy to coordinate with registry maintainers if there's appetite to make program-address tagging a first-class field for financial/escrow plugins. The plugin's standalone repo is up at casematelabs/holdfastprotocol-eliza-plugin, and the registry PR is at elizaos-plugins/registry#348.

— Matthew @ Casemate Labs

[MrTalecky]

The SIMD-48/secp256r1 path is significantly stronger than what I described for EVM. On the EVM side, the delegated signer is a software key — the owner's hardware wallet signs the EIP-712 delegation, but the agent's short-lived signing key is not hardware-attested. What you're building (secp256r1 key bound to an AgentWallet PDA via the precompile) means the key material itself can't be extracted even by the application. That's a materially harder-to-compromise agent identity. The "gate signer: with a devnet warning until the PDA path lands" decision is exactly right — the ergonomics gap is much cheaper to fix than the security gap.

On the reputation write path: I misread the architecture from your initial post. CPI at every terminal pact event means the ReputationAccount is write-authoritative at settlement time, not at indexer sync time — the score is necessarily consistent with the settlement history, not just correlated with it. The consumer-reads-indexer risk is real but bounded: for any reputation-gated decision, polling the PDA directly gets the canonical value. Might be worth surfacing that as an explicit entry point in the plugin or registry docs — something like a read_reputation(agent_address) → ReputationAccount call as the canonical query pattern, rather than leaving it implicit for consumers to discover.

On the registry PR: we have a similar open PR for eliza-plugin-flipcoin. The program-address-as-first-class-field ask is worth raising either in #348 or a separate registry discussion — it benefits any financial/escrow plugin, not just Holdfast. The release-manifest.json approach you described is the right precursor; making it a queryable registry field turns it from documentation into an install-time security constraint. Happy to add a comment to the PR supporting it if that'd help get maintainer traction.

[meanstackofdoom]

Thanks @MrTalecky — three quick responses to your good self.

On secp256r1 vs delegation strength. Glad the distinction lands. Yes — the hardware-attested path means even compromised agent code can't exfiltrate the signing key. Will make sure that's surfaced as an explicit invariant in the audit scope, not just an emergent property.

On the canonical PDA read entry point. It already exists in the SDK as client.reputation.get(agentPubkey) — reads the on-chain ReputationAccount PDA directly, no indexer in the path. Just landed proper docs for it at docs/quickstart.md. You're right that it should be louder; I'll add an explicit "for reputation-gated decisions, read the PDA, not the indexer" callout in the integration guide so consumers don't have to derive it.

On the registry program-address ask. Strongly yes to the supporting comment — would help with maintainer traction. I'll draft the proposal as a separate registry discussion (rather than keeping it inline on #348) so it can be evaluated on its own merits and benefit any financial/escrow plugin, not just Holdfast. Will tag you when it goes up.

— Matthew @ Casemate Labs

[meanstackofdoom]

Quick update since the original post.

Devnet redeploy complete. Both programs are live at canonical keypairs (vaultpact 2chF47Db…, vaultpact_escrow CAZMkHiE…). Addresses are pinned in a release-manifest.json consumed by the SDK runtime and the dashboard.

SDK fixes shipped. registerAgentWallet() now passes sha256(preimage) as the secp256r1 message payload — the format the SIMD-48 precompile compares against. ASSOCIATED_TOKEN_PROGRAM_ID constant typo corrected. EscrowModule.getEscrowEvents types are now part of the public API surface for indexer pagination consumers.

End-to-end verified. Quickstart parity test passes. createPact → claimReleased lifecycle smoke ran clean against the redeployed devnet programs. Lifecycle proof script lives in the SDK repo at scripts/cas2-full-lifecycle-explicit-arbiter.ts.

Program-side compatibility. Extended verify_secp256r1_precompile to accept either the 32-byte digest (preferred) or the raw preimage (the program hashes internally). Keeps both old and new SDK builds working against the redeployed program. The dual-mode path will be reviewed in the next audit pass.

Public surface, all linkable now:

• Monorepo — casematelabs/holdfastprotocol (just made public)
• SDK — casematelabs/holdfastprotocol-sdk (with docs/quickstart.md and docs/troubleshooting.md)
• Plugin — casematelabs/holdfastprotocol-eliza-plugin

Up next:

• Per @MrTalecky's signer-injection point — drafting the on-chain delegation interface (Holdfast roadmap) to replace raw signer: in plugin config.
• Registry PR #348 is updated, ready for maintainer review.
• Drafting a separate registry discussion proposing program-address-as-first-class-field for financial/escrow plugins.

— Matthew @ Casemate Labs

[MrTalecky]

The client.reputation.get(agentPubkey) entry point is the right design — a named SDK call with an explicit return type beats "derive the PDA address and parse the account layout yourself." The integration guide callout ("for reputation-gated decisions, read the PDA, not the indexer") will matter most for third-party consumers composing this into character graphs without reading the internals first.

Congrats on the public repos. The lifecycle proof at scripts/cas2-full-lifecycle-explicit-arbiter.ts being readable is useful — explicit arbiter path in a smoke test makes the terminal escrow event semantics reviewable without requiring a full read-through of the escrow program source.

Looking forward to the registry discussion when it goes up. Will add a supporting comment on program-address-as-first-class-field. Keeping it separate from #348 is the right call — it's a registry-level design question that applies to any financial or escrow plugin, not just Holdfast, and should stand on its own merits.

[meanstackofdoom]

Thanks @MrTalecky.

On the integration-guide callout. Good framing, "composing into character graphs without reading the internals first" is the consumer profile we should optimize for. I'll bias the integration guide toward the read-the-PDA pattern as the canonical entry point and treat indexer-paginated history as the secondary path, not the lead.

On the lifecycle proof script. The explicit-arbiter variant is the right shape — it forces the dispute-resolution code path into the smoke run rather than letting it sit unexercised as such. The cas2--prefixed filename is on a coordinated rename pass; it's referenced from the SDK quickstart, so renaming will happen in one change rather than churn the public docs twice.

On the registry discussion. Drafting it this week. Will tag you when it goes up so your supporting comment doesn't have to dig for the link.

btw, thanks!

— Matthew @ Casemate Labs

[meanstackofdoom]

Filed the standalone RFC as promised: #7513 — RFC: First-class on-chain program addresses in plugin registry entries.

@MrTalecky — your support comment over there would be much appreciated when you have a moment. Filed it standalone so it can be evaluated on its own merits and benefit any financial / escrow plugin, not just Holdfast.

[musaabhasan]

One production control I would add around the plugin is to treat pact execution as an auditable state machine, not only a set of SDK calls. Each createPact, submit, release, refund, or dispute action should emit a compact evidence record with an idempotency key, actor signer, attestation/delegation bounds, policy snapshot, pre/post balances, release condition evaluated, and the source of the verdict.

That matters for reputation as well. Reputation should probably consume finalized pact outcomes after the dispute/appeal window, rather than task submission or optimistic completion. Otherwise a malicious agent can farm apparent success before counterparties have a chance to challenge.

A useful negative-test set before a production release would be:

• replaying releasePact with the same nonce/idempotency key
• stale oracle or evaluator verdict used after its validity window
• indexer result disagreeing with the PDA/account state
• program upgrade authority changing after registry verification
• signer delegation or hardware attestation expiring mid-pact
• reputation update attempted before final settlement

Those tests would make the security story much clearer for anyone composing this into higher-value agent workflows.

[luisllaver]

Relevant AURA Feature for Holdfast Protocol Integration

The Holdfast Protocol's reputation layer and escrow functionality share similarities with AURA's trust and reputation features. Specifically, AURA's Verifiable Claims API (https://api.auraopenprotocol.org/verifiable-claims) allows agents to verify and store reputation scores and track records on-chain, similar to Holdfast Protocol's VerifTier-scored track records.

By integrating AURA's Verifiable Claims API, the Holdfast Protocol plugin for ElizaOS agents could leverage AURA's existing infrastructure to streamline reputation management and escrow processes. This could enhance the overall trust and security of the ElizaOS ecosystem.

How do you envision the integration of AURA's Verifiable Claims API with the Holdfast Protocol plugin? Would you like to explore this further and discuss potential implementation details?