feat: pow-attest oracle implementation (PoW-gated Schnorr DLC, GitHub PR/issue conditions)

[zekebuilds-lab]

Hey bennyhodl, great work on dlcdevkit. I have been building a PoW-gated Schnorr attestation oracle called pow-attest (https://attest.powforge.dev) and think it would slot in cleanly as a fourth oracle implementation alongside kormir, nostr, and p2p_derivatives.

What pow-attest does

Two condition types supported right now:

• github_pr_merged -- locks a DLC contract that releases when a specific PR gets merged
• github_issue_closed -- same idea but for issue close

Registration is PoW-gated (SHA-256 hashcash, difficulty 18). The oracle signs attestations with BIP-340 Schnorr using key 2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5, attestation tag DLC/oracle/attestation/v0. The use case is bug-bounty auto-release: lock funds to a DLC, merge the PR, oracle signs RELEASED.

There is a JS client already shipped (@powforge/attest-client on npm) and I would love to add a Rust client behind a pow-attest feature flag, same shape as p2p_derivatives.rs.

Compatibility questions before I open a PR

I dug into the ddk_manager::Oracle trait and found two things worth asking about:

1. oracle_announcement_signature -- our /api/v1/bounty/:id/announcement endpoint returns JSON without a Schnorr signature over the OracleEvent TLV. Looking at p2p_derivatives.rs I am not sure if dlcdevkit enforces this or if it is advisory. Happy to add the signature server-side if it is required.

2. event_descriptor -- our outcomes are binary (RELEASED / PENDING). I am planning to map this to EnumerationEventDescriptor { outcomes: ["RELEASED", "PENDING"] } in the Rust client. Does that look right to you, or would a DigitDecompositionEventDescriptor be more appropriate for the manager internals?

Proposed PR shape

• ddk/src/oracle/pow_attest.rs (~150 LOC, mirrors p2p_derivatives.rs)
• ddk/examples/pow_attest.rs (mirrors lightning.rs, swaps KormirOracleClient for PowAttestOracleClient)
• Feature flag: pow-attest in ddk/Cargo.toml

Happy to answer any questions about the oracle design. Just wanted to check in before surprising you with a PR out of nowhere.

[zekebuilds-lab]

Quick follow-up: I added a test vectors page at https://attest.powforge.dev/test-vectors with deterministic sha256 inputs and expected outputs for every construction (PoW format, ALIVE/DEAD/RELEASED outcome hashes, check-in sig message). Might be useful for verifying a Rust client implementation against known-good values.

[zekebuilds-lab]

Wrote up the full use case and JavaScript implementation walkthrough on DEV.to if anyone wants more context on the oracle model: https://dev.to/zekebuilds/trustless-bug-bounty-releases-with-a-pow-gated-dlc-oracle-46f0

The test vectors page at https://attest.powforge.dev/test-vectors has the deterministic sha256 values for all three outcome types so a Rust implementer can verify the hashing matches before wiring up the client.

[zekebuilds-lab]

One more update: attest.powforge.dev now serves binary TLV bytes for both OracleAnnouncement (type 55332) and OracleAttestation (type 55400), so the JSON-only concern from my opening comment is resolved. Means a dlcdevkit Oracle impl can read the streams straight into dlc_messages::oracle_msgs::OracleAnnouncement::read and OracleAttestation::read without a translation layer.

Concrete PR shape I am thinking:

// ddk/src/oracle/pow_attest.rs
pub struct PowAttestOracle {
    host: String,
    client: reqwest::Client,
    pubkey: XOnlyPublicKey, // fetched once from GET {host}/api/v1/info
}

impl Oracle for PowAttestOracle {
    fn get_public_key(&self) -> XOnlyPublicKey {
        self.pubkey
    }

    async fn get_announcement(&self, event_id: &str) -> anyhow::Result<OracleAnnouncement> {
        let bytes = self.client
            .get(format!("{}/api/v1/bounty/{}/announcement.tlv", self.host, event_id))
            .send().await?.bytes().await?;
        let mut cursor = std::io::Cursor::new(bytes);
        Ok(OracleAnnouncement::read(&mut cursor)?)
    }

    async fn get_attestation(&self, event_id: &str) -> anyhow::Result<OracleAttestation> {
        let bytes = self.client
            .get(format!("{}/api/v1/bounty/{}/attestation.tlv", self.host, event_id))
            .send().await?.bytes().await?;
        let mut cursor = std::io::Cursor::new(bytes);
        Ok(OracleAttestation::read(&mut cursor)?)
    }
}

The event_id is the bounty UUID returned from POST /api/v1/bounty. The attestation endpoint stays 404 with state: "PENDING" JSON until the GitHub condition fires, then flips to a 200 with the TLV body. I can either retry-poll inside get_attestation or surface the pending state as an error variant, whichever fits ddk patterns better.

Two structural questions before I cut the PR:

1. Does examples/pow_attest.rs work, or would you rather a separate oracle/ examples folder if more wrappers come along later?
2. Feature gate as pow-attest in ddk/Cargo.toml, mirroring how kormir and p2p_derivatives are gated. Sound right?

Gonna start the branch this week unless you flag a different shape.

[zekebuilds-lab]

Opened the PR: #159 — feat(oracle): add PowAttestOracleClient for attest.powforge.dev.

It implements both ddk_manager::Oracle and crate::Oracle (with name() = "pow-attest"), follows the kormir.rs shape (HTTP client + optional Arc<Logger>), and gates everything under a new pow-attest feature flag that reuses the existing optional reqwest dep.

The round-trip gate I mentioned upthread (ddk_messages::oracle_msgs::OracleAnnouncement::read against the live /api/v1/bounty/<id>/announcement.tlv) was run before opening — the server returns the full TLV including the 4-byte BigSize outer header (fdd824 c9 for the 201-byte payload), so the skeleton skips those 4 bytes (&bytes[4..]) before reading. There is a code comment in read_tlv_payload calling out the BigSize multi-byte length case if payloads ever grow past 252 bytes.

The static fixture used by the unit test (6ba7b810-…) is the same bounty kept on attest.powforge.dev for downstream-test purposes.

Happy to address feedback on naming, the static fixture format (currently a hex const in-tree), error variants, or anything else.