Skip to content

MYT Machine v0.4.0 — Phase 4D

Choose a tag to compare

View all tags
@MYT-Core MYT-Core released this 07 Sep 05:08
v0.4.0
034e457

MYT Machine v0.4.0

Phase 4D

Payment Requests, Invoices and API Billing.

Approved source commit: 034e4576b4cd427f2f213e4fd0131104502c69f2.

What's new

  • Versioned, immutable MYT payment-request artifacts with deterministic serialization, exact atomic-unit amounts, explicit network binding, bounded fields and strict JSON parsing.
  • A separate local invoice lifecycle: PENDING -> PAID or PENDING -> EXPIRED. Both final states are terminal.
  • SQLite invoice persistence, idempotent creation and atomic duplicate-transaction protection within each ledger/network.
  • Read-only native OutProofV2 verification against the invoice's recipient, exact requested amount and canonical request message, with a configurable positive confirmation threshold (default: 10).
  • Programmatic billing and service gating through BillingService, additional payment-request and invoice CLI commands, and an authenticated WSGI REST reference interface.
  • Expanded Linux/Windows CI, regression, parser, concurrency, secret-redaction and packaging coverage.

Security model

Phase 4D does not automatically spend funds. Verification invokes only validate_address and check_tx_proof; existing Phase 4A payments remain separately explicit operations. No wallet seed or private-key handling was added in Phase 4D.

A PAID invoice is a local service decision based on verified payment evidence, confirmation policy and protected persistent state. Payment verification depends on a correctly configured, trusted and synchronized wallet/daemon. Neither the proof nor the invoice attributes a payer wallet address, customer identity or Machine Identity.

The REST interface is a trusted billing-operator API. Keep its bearer token server-side, protect transport and access, and configure production request limits and timeouts. Customer authentication, server-selected prices/recipients and one-time service fulfillment remain application responsibilities. require_paid does not replace them.

Verification

The approved commit passed all 14 GitHub Actions jobs.

  • 318 repository tests: Phase 4A 66, Phase 4B 62, Phase 4C 47 and Phase 4D 143.
  • The final security review exercised Linux and native Windows on Python 3.10, 3.12 and 3.13, with cryptography==50.0.0 and 50.0.1.
  • Linux: 318 passed per configuration. Windows: 313 passed and five documented permission/symlink skips per configuration; those checks ran on Linux.
  • An additional 22 independent adversarial tests passed on Linux and Windows, including separate-process SQLite races.
  • Ruff, Bandit, compilation, dependency consistency/audits and packaging checks passed in the final review.
  • The release packages were rebuilt from a fresh detached checkout. Distribution checks, installed-wheel version/import/entrypoint checks, the full regression suite and a deterministic CLI/Fake-RPC billing E2E passed before publication.

Native MYT proof semantics were reviewed against the Core source. Fake-RPC tests exercise application policy and integration; they do not establish the validity of a real on-chain payment. No real MYT payment was performed for this release workflow.

Compatibility

  • Python 3.10 or newer.
  • Distribution: myt-machine-settlement; import: myt_machine; CLI: myt-machine.
  • Runtime dependency remains cryptography>=50.0.0; Phase 4D adds no new runtime dependency.
  • Phase 4A, 4B and 4C interfaces remain backward compatible.
  • No MYT Core, consensus, blockchain, transaction-format, Wallet-RPC-schema or HF17 changes. No node upgrade is required for this SDK release.

Community contribution

Special thanks to @fallacyofall for the original Phase 4D payment-request reference implementation and follow-up fixes. The contribution was fully reviewed and served as a foundation for parts of the final implementation. The final production design was reworked and integrated with preserved contributor attribution.

PR #1 was superseded and closed, not directly merged. The request schema and state handling were revised to address architectural and security limitations. The official implementation commit preserves the Co-authored-by trailer.

Upgrade

Download the wheel and SHA256SUMS.txt from this release. Verify the downloaded wheel against its checksum entry, then install it into your Python environment:

python -m pip install --upgrade ./myt_machine_settlement-0.4.0-py3-none-any.whl
python -m pip check
python -c "import myt_machine; print(myt_machine.__version__)"
myt-machine --help
myt-machine payment-request --help
myt-machine invoice --help

The version check should print 0.4.0. These assets are distributed through GitHub; this workflow does not publish the package to PyPI.

Read the payment-request protocol, invoice lifecycle and verification, and SDK/CLI/REST billing guide before integrating billing.

Known limitations

  • Requests are unsigned in v0.4.0 and require delivery through an authenticated application channel. Machine Identity and fresh liveness challenges remain separate capabilities.
  • Verification must complete at the required depth before invoice expiry. Late payments require manual handling; v1 does not provide partial/overpayment accounting.
  • PAID is terminal and is not automatically revoked after a later deep reorganization. Confirmation depth does not establish immediate spendability for custom transaction unlock times.
  • Transaction reuse protection depends on preserving a shared ledger. Separate databases or deleted history cannot enforce global uniqueness. Previously unallocated transactions can satisfy a fresh invoice-bound proof; mining time relative to request creation is not enforced.
  • The database and application are trusted local state, without cryptographic tamper evidence. Protect files, ACLs, journals and backups. Invoice terms and TXIDs can reveal business activity; minimize metadata and prefer dedicated merchant subaddresses.
  • The WSGI adapter requires production hosting controls. No public REST deployment is part of this release. MCP remains a later integration layer.

Roadmap

Phase Status
4A - Machine Settlement SDK Complete
4B - Agent Identity Complete
4C - Signed Address Binding Complete
4D - Payment Requests / Invoices / API Billing Complete
4E - Agent Reputation Not started
4F - ZK Selective Disclosure Not started

Contributors

fallacyofall
Assets 5
Loading