fix(sdk): align DPNS builder validation with consensus, harden embedder seams

Review follow-ups on the transport-free series:

- The DPNS document builder validated labels with is_valid_username, whose
  consecutive-hyphen rejection is stricter than the DPNS contract's schema
  pattern - consensus accepts names like ab--cd. Split the check: new
  is_consensus_valid_label matches the contract pattern exactly and gates
  the builder (so dash-sdk's register_dpns_name no longer refuses
  consensus-valid labels), while is_valid_username keeps the stricter
  policy for its existing FFI/wasm gates and now documents the difference.
- verify_documents_response rejects aggregate projections (COUNT/SUM/AVG)
  up front with a pointer to the aggregate proof helpers, instead of
  surfacing an opaque low-level proof error; try_from_request documents
  that it mirrors the server's wire-shape decode, not validate_and_route
  business rules.
- The CI transport-leak guard also asserts wasm-sdk's wasm32 tree stays
  free of the native transport stack.
- The proof-vector corpus gains a README with an explicit coverage matrix:
  the four documents-family cases pin query shape and clean decode failure
  but stop before the BLS check (placeholder payloads in the fixture
  state); identity, contested, and quorum-sig families run the full
  pipeline. This corrects the corpus commit's broader claim.

Author: PastaPastaPasta

packages/dash-platform-queries/src/documents/document_query.rs

@@ -400,6 +400,15 @@ impl DocumentQuery {
     /// `contract` must be the data contract the request targets — the
     /// request's `data_contract_id` is checked against `contract.id()`
     /// and the named document type must exist on it.
+    ///
+    /// Scope caveat: this mirrors the server's *wire-shape* decoding
+    /// (shared clause decoders), not its full `validate_and_route`
+    /// business rules — e.g. SUM/AVG requiring a non-empty field,
+    /// GROUP BY being illegal with SELECT DOCUMENTS, or HAVING being
+    /// unimplemented are enforced server-side only. A request violating
+    /// those decodes here but can never yield a provable response from
+    /// a real server, so this only matters for fabricated
+    /// request/response pairs.
     pub fn try_from_request(
         request: GetDocumentsRequest,
         contract: Arc<DataContract>,
@@ -653,6 +662,19 @@ pub fn verify_documents_response(
             error: format!("failed to decode GetDocumentsRequest into a DocumentQuery: {e}"),
         }
     })?;
+    // This entry point verifies plain document fetches only. An aggregate
+    // projection (COUNT/SUM/AVG) is proved with a different proof shape;
+    // handing it to the Documents verifier would surface as an opaque
+    // low-level proof error, so reject it up front instead.
+    if query.select != drive::query::SelectProjection::documents() {
+        return Err(drive_proof_verifier::Error::RequestError {
+            error: format!(
+                "verify_documents_response only verifies plain document fetches; the request \
+                 carries a {:?} projection — use the aggregate proof helpers instead",
+                query.select.function
+            ),
+        });
+    }
     <Documents as FromProof<DocumentQuery>>::maybe_from_proof_with_metadata(
         query,
         response,

packages/dash-platform-queries/src/dpns_usernames.rs

@@ -33,7 +33,7 @@ fn hash_double(data: Vec<u8>) -> [u8; 32] {
 /// `salt`, whose double-SHA256 over `salt ‖ "<normalized label>.dash"`
 /// becomes the preorder's `saltedDomainHash`.
 ///
-/// The `label` must satisfy [`is_valid_username`]; the raw label is stored
+/// The `label` must satisfy [`is_consensus_valid_label`]; the raw label is stored
 /// in the domain document's `label` property while its
 /// [homograph-safe](convert_to_homograph_safe_chars) form is stored in
 /// `normalizedLabel`.
@@ -46,10 +46,10 @@ pub fn build_dpns_preorder_and_domain_documents(
     entropy: [u8; 32],
     salt: [u8; 32],
 ) -> Result<(Document, Document), Error> {
-    if !is_valid_username(label) {
+    if !is_consensus_valid_label(label) {
         return Err(Error::InvalidInput(format!(
             "Invalid DPNS label \"{label}\": must be 3-63 characters, alphanumeric and hyphens \
-             only, starting and ending with an alphanumeric character, without consecutive hyphens"
+             only, starting and ending with an alphanumeric character"
         )));
     }
 
@@ -161,15 +161,34 @@ pub fn convert_to_homograph_safe_chars(input: &str) -> String {
         .collect()
 }
 
-/// Check if a username is valid according to DPNS rules
-///
-/// A username is valid if:
-/// - It's between 3 and 63 characters long
-/// - It starts and ends with alphanumeric characters (a-zA-Z0-9)
-/// - It contains only alphanumeric characters and hyphens
-/// - It doesn't have consecutive hyphens (enforced by the pattern)
+/// Check whether a label satisfies the DPNS contract's `label` schema
+/// pattern — exactly what consensus enforces, nothing stricter.
 ///
 /// Pattern: `^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$`
+/// (3-63 characters, alphanumeric and hyphens, alphanumeric at both ends;
+/// consecutive hyphens ARE allowed by consensus).
+pub fn is_consensus_valid_label(label: &str) -> bool {
+    if label.len() < 3 || label.len() > 63 {
+        return false;
+    }
+    let chars: Vec<char> = label.chars().collect();
+    if !chars[0].is_ascii_alphanumeric() || !chars[chars.len() - 1].is_ascii_alphanumeric() {
+        return false;
+    }
+    chars[1..chars.len() - 1]
+        .iter()
+        .all(|&ch| ch.is_ascii_alphanumeric() || ch == '-')
+}
+
+/// Check if a username is valid according to this crate's recommended
+/// client-side policy: the consensus pattern plus a stricter rejection of
+/// consecutive hyphens.
+///
+/// This is deliberately narrower than [`is_consensus_valid_label`] — a name
+/// like `ab--cd` is consensus-valid but rejected here, matching the
+/// pre-existing policy of the mobile SDK FFI and wasm-sdk gates. Callers
+/// that must accept every consensus-valid label should use
+/// [`is_consensus_valid_label`] instead.
 ///
 /// # Arguments
 ///
@@ -179,38 +198,7 @@ pub fn convert_to_homograph_safe_chars(input: &str) -> String {
 ///
 /// Returns `true` if the username is valid, `false` otherwise
 pub fn is_valid_username(label: &str) -> bool {
-    // Check length
-    if label.len() < 3 || label.len() > 63 {
-        return false;
-    }
-
-    let chars: Vec<char> = label.chars().collect();
-
-    // Check first character (must be alphanumeric)
-    if !chars[0].is_ascii_alphanumeric() {
-        return false;
-    }
-
-    // Check last character (must be alphanumeric)
-    if !chars[chars.len() - 1].is_ascii_alphanumeric() {
-        return false;
-    }
-
-    // Check middle characters (can be alphanumeric or hyphen)
-    for &ch in &chars[1..chars.len() - 1] {
-        if !ch.is_ascii_alphanumeric() && ch != '-' {
-            return false;
-        }
-    }
-
-    // Additional check: no consecutive hyphens (good practice)
-    for i in 0..chars.len() - 1 {
-        if chars[i] == '-' && chars[i + 1] == '-' {
-            return false;
-        }
-    }
-
-    true
+    is_consensus_valid_label(label) && !label.contains("--")
 }
 
 /// Check if a username is contested (requires masternode voting)
@@ -367,7 +355,7 @@ mod tests {
         let contract = dpns_contract();
         let identity_id = Identifier::from([2u8; 32]);
 
-        for bad in ["", "ab", "-alice", "alice-", "alice--bob", "alice_bob"] {
+        for bad in ["", "ab", "-alice", "alice-", "alice_bob"] {
             let result = build_dpns_preorder_and_domain_documents(
                 &contract,
                 identity_id,
@@ -382,6 +370,27 @@ mod tests {
         }
     }
 
+    /// Consecutive hyphens are consensus-valid (the DPNS contract pattern
+    /// `^[a-zA-Z0-9][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]$` allows them), so the
+    /// builder must accept them even though the stricter client-side
+    /// [`is_valid_username`] policy rejects them.
+    #[test]
+    fn build_dpns_documents_accepts_consensus_valid_double_hyphen() {
+        let contract = dpns_contract();
+        let identity_id = Identifier::from([2u8; 32]);
+
+        assert!(is_consensus_valid_label("alice--bob"));
+        assert!(!is_valid_username("alice--bob"));
+        build_dpns_preorder_and_domain_documents(
+            &contract,
+            identity_id,
+            "alice--bob",
+            [3u8; 32],
+            [4u8; 32],
+        )
+        .expect("consensus-valid label with consecutive hyphens must build");
+    }
+
     #[test]
     fn test_convert_to_homograph_safe_chars() {
         assert_eq!(convert_to_homograph_safe_chars("alice"), "a11ce");