Skip to content

chore(deps): bump tnt-core-bindings 0.10.9 → 0.11.0 for unified approveService#1402

Merged
drewstone merged 1 commit into
mainfrom
drew/bump-tnt-core-bindings-v0.11
May 5, 2026
Merged

chore(deps): bump tnt-core-bindings 0.10.9 → 0.11.0 for unified approveService#1402
drewstone merged 1 commit into
mainfrom
drew/bump-tnt-core-bindings-v0.11

Conversation

@drewstone
Copy link
Copy Markdown
Contributor

tnt-core PR #119 collapsed five `approveServiceWith*` entrypoints into a single
`approveService(ApprovalParams)`. The Rust binding regen ships in
tnt-core PR #120 as
`bindings-v0.11.0`. This PR threads the new API through the blueprint workspace.

Changes

  • `Cargo.toml`: workspace `tnt-core-bindings` pin → ^0.11.0. Currently pinned at
    the bindings PR's branch while tnt-core PR [BUG] During Key rotation, we should use the correct signature scheme #120 is in flight; switch to
    `tag = "bindings-v0.11.0"` once that PR merges and the release tag publishes.
  • `crates/clients/tangle/src/client.rs`:
    • new `approve_service_with_params(params)` — direct passthrough for callers
      that need to register a BLS pubkey or pin TEE attestation profiles
    • `approve_service(request_id)` — minimal approval, no optional capabilities
    • `approve_service_with_commitments(request_id, commitments)` — common
      per-asset path, BLS / TEE skipped
      Both convenience helpers build `Types.ApprovalParams` with empty / zero
      defaults for the capabilities they don't use.
  • `cli/src/command/service/mod.rs`: legacy CLI signature `(client, request_id,
    staking_percent)` kept — `staking_percent` is now ignored (derived on-chain
    from `securityCommitments[0].exposureBps` or defaults to 100%). Documented in
    the doc comment.

Why this is correct

  • BLS stays opt-in. Operators that don't register a BLS pubkey can still
    approve and run services; `JobsAggregation` only reverts when an unregistered
    operator is asked to participate in a BLS aggregate.
  • TEE commitments are opt-in. Operators that don't bind a TEE profile pass an
    empty array; the contract no-ops.
  • The two convenience helpers preserve the common shapes used today
    (`approve_service`, `approve_service_with_commitments`); callers don't need
    to construct `ApprovalParams` themselves unless they're using BLS or TEE.

Coordination

Companion PRs that must land in lockstep:

  • tnt-core #120 — regen + tag bindings-v0.11.0
  • tangle-network/dapp follow-up — regenerate ABI + rewrite `useServiceApproveTx`

After tnt-core #120 merges + the tag publishes, this PR's `Cargo.toml` flips
from `branch = "..."` to `tag = "bindings-v0.11.0"` in a tiny follow-up
commit.

Test plan

  • Pre-push hook ran cargo build / clippy / test on the workspace
    against the branch-pinned bindings — pushed successfully
  • Re-run after tag publish to confirm the tag-pinned dependency resolves
  • CI to run the full suite

…oveService

tnt-core PR #119 collapsed five approveServiceWith* entrypoints into a single
approveService(ApprovalParams). The Rust binding regen ships in tnt-core
PR #120 as `bindings-v0.11.0`. This PR threads the new API through the
blueprint workspace.

## Changes

- `Cargo.toml`: workspace `tnt-core-bindings` pin → ^0.11.0, tag → bindings-v0.11.0
- `crates/clients/tangle/src/client.rs`:
  - new `approve_service_with_params(params)` — direct passthrough for callers
    that need to register BLS or pin TEE commitments
  - `approve_service(request_id)` — minimal approval, no optional capabilities
  - `approve_service_with_commitments(request_id, commitments)` — common
    per-asset path, BLS / TEE skipped
  Both helpers build `Types.ApprovalParams` with empty / zero defaults for the
  capabilities they don't use, so opting out is the default.
- `cli/src/command/service/mod.rs`: legacy CLI signature `(client, request_id,
  staking_percent)` kept — `staking_percent` is now ignored (derived on-chain
  from `securityCommitments[0].exposureBps` or defaults to 100%). Documented in
  the doc comment.

## Verification

- Local `cargo check -p blueprint-client-tangle` once `bindings-v0.11.0` tag is
  published. CI runs the canonical build against the resolved tag.
- Downstream `ai-agent-sandbox-blueprint` picks up the new bindings transitively
  on its next `cargo update -p blueprint-sdk`.
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 5, 2026

PR Quality Gate Summary

  • Status: fail
  • Selected class: not set
  • Required class: Class D
  • Reason: High-risk protocol/security/runtime path changed: crates/clients/tangle/src/client.rs
  • Changed files: 3

Blocking issues

  • Missing required section: '## Summary'
  • Missing required section: '## Change Class'
  • Missing required section: '## Behavior Contract'
  • Missing required section: '## Risk And Scope'
  • Missing required section: '## Verification'
  • Missing required section: '## Harness Evidence'
  • Missing required section: '## Checklist'
  • Change Class section must specify 'Selected class: ...'
  • Verification section must include at least one command (inline or fenced).

@drewstone drewstone merged commit 48202ec into main May 5, 2026
24 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant