MYT Machine v0.5.0 Released — Phase 4E: Agent ReputationWe have officially released:
MYT Machine v0.5.0This release completes:
Phase 4E — Agent ReputationRelease:
https://github.com/MYT-Core/MYT-Machine/releases/tag/v0.5.0Final release commit:
ff1624ff6263bfd4142550391a381f96006a0413
The v0.5.0 tag points exactly to this reviewed commit.
This is another major step in the MYT Machine roadmap.
The system now covers:
4A – Machine Settlement SDK COMPLETE
4B – Agent Identity COMPLETE
4C – Signed Address Binding COMPLETE
4D – Payment Requests / Invoices / API Billing COMPLETE
4E – Agent Reputation COMPLETE
4F – ZK Selective Disclosure NEXT
With 4E, MYT Machine now has an off-chain reputation layer that connects the identity, wallet-binding and settlement primitives built in the previous phases.
However, we deliberately did NOT build a universal "trust score".
That distinction is important.
What problem is Phase 4E trying to solve?Imagine two autonomous software agents that have never interacted before.
Agent A wants to buy a service from Agent B.
By the end of Phase 4D, the system could already establish:
Who is the machine?
↓
Phase 4B Machine Identity
Which MYT settlement address is bound to it?
↓
Phase 4C Signed Address Binding
What should be paid?
↓
Phase 4D Invoice
Was the invoice correctly settled?
↓
Phase 4D payment verification
But one important question was still missing:
"Has this machine built any reputation from previous interactions?"
Phase 4E introduces the primitives required to answer that question without pretending that reputation is globally objective.
The core design principlePhase 4E separates three fundamentally different things:
1. OBJECTIVE LOCAL OBSERVATIONS
2. SIGNED SUBJECTIVE OPINIONS
3. LOCAL POLICY OUTPUT
They are intentionally not collapsed into one number.
1. Objective local observationsFor example, a local MYT Machine installation may verify that:
- an invoice was PAID
- a fresh native MYT payment proof is valid
- the expected amount matches
- the network matches
- the recipient matches
- the recipient address has a valid Phase 4C binding
- the binding belongs to Machine Identity X
The resulting observation can therefore say, in simplified language:
"Machine Identity X is associated with the recipient
of this locally verified MYT settlement."
It does NOT mean:
"Machine X delivered a good service."
Payment is evidence of settlement.
Payment is not proof of service quality.
2. Signed subjective opinionsA Machine Identity may sign an attestation about another Machine Identity.
For example:
Issuer:
Machine A
Subject:
Machine B
Category:
SERVICE_INTERACTION
Outcome:
POSITIVE
This proves:
The controller of Machine A's identity key
authorized this exact attestation.
It does NOT prove:
- that Machine A is telling the truth
- that A and B are independently controlled
- that the service really happened
- that the service quality was actually good
- that A represents a unique person or company
That distinction is fundamental to the 4E model.
3. Local policy outputApplications can decide which issuers they trust.
For example:
Trusted issuers:
A
C
F
Maximum contribution per issuer:
1
Maximum attestation age:
90 days
Require linked settlement:
yes
Another application may use a completely different policy.
Therefore there is no protocol-level value such as:
MYT REPUTATION SCORE = 87/100
That would create a false sense of objectivity.
Phase 4E instead exposes verifiable evidence and deterministic local policy.
Signed Reputation Attestationsv0.5.0 introduces versioned reputation artifacts.
The current attestation schema contains:
type
version
issuer
statement
id
signature
The signed statement contains:
subject_machine_id
network
issued_at
category
outcome
evidence_digest
Current category:
Current outcomes:
The artifact is immutable and canonicalized before signing.
The protocol reuses the existing Phase 4B Ed25519 Machine Identity system.
No new identity-key system was introduced.
No custom signature primitive was introduced.
The Phase 4E signature contexts are domain-separated from the other MYT Machine signature types.
Mutating a signed semantic field invalidates verification.
This includes:
- subject
- network
- outcome
- evidence digest
- timestamp
- issuer
- version
Reputation artifacts use deterministic canonical encoding and SHA-256-based identifiers.
Domain separation is applied to the attestation and revocation content.
The attestation ID takes the form:
myt-reputation-v1:<sha256>
This is important for interoperability, signature consistency and replay protection.
The parser rejects ambiguous and malformed input including:
- duplicate JSON keys
- escaped duplicate keys
- unknown fields
- missing fields
- malformed UTF-8
- BOM
- invalid Unicode controls
- oversized artifacts
- invalid Machine IDs
- invalid enums
- invalid versions
- bool/int confusion
- floating-point values where integers are required
- exponent notation
- NaN
- Infinity
- invalid timestamps
- trailing data
Allowed transport variations normalize back to the same canonical representation.
Replay and double-counting protectionA valid attestation may legitimately be transmitted more than once.
That must not mean it contributes more than once to reputation.
Phase 4E therefore handles cases such as:
same artifact imported twice
same bytes through different input paths
same signature repeatedly
concurrent duplicate imports
same artifact after restart
canonical-equivalent representations
Attestation IDs and canonical artifact digests are unique.
Settlement observations are additionally protected by unique network/transaction and network/request relationships.
One verified payment cannot silently become several objective settlement events.
Self-reputationSelf-attestations are rejected.
issuer_machine_id == subject_machine_id
↓
REJECT
However, this does NOT solve Sybil attacks globally.
An attacker can still create:
Machine A
Machine B
Machine C
Machine D
and have those identities interact with or attest each other.
That is why local trust policy is a separate part of Phase 4E.
Sybil resistance — deliberately NOT overclaimedA Machine Identity is a cryptographic identity.
It is NOT proof of:
one human
one company
one physical machine
one independent controller
Anyone may create multiple Machine Identities.
Therefore Phase 4E does not claim global Sybil resistance.
The default local policy trusts no arbitrary unknown issuer automatically.
Applications may configure:
issuer allowlists
per-issuer contribution caps
evidence-age requirements
settlement-linkage requirements
These are local trust-policy mechanisms.
They are not MYT consensus and not a global identity system.
Signed RevocationsPhase 4E also introduces signed reputation revocations.
The issuer that created an attestation may later authorize a revocation of that attestation.
A valid revocation proves:
The original issuer authorized the revocation statement.
The original attestation remains historically present, but applicable policy and summaries can exclude it.
Important limitation:
A signed timestamp remains a signed claim.
Phase 4E does not provide a trusted global clock.
An offline verifier also cannot know about a revocation it has never received.
Therefore the system does not claim globally synchronized revocation knowledge.
Integration with Phase 4CPhase 4E reuses the existing Phase 4C Signed Address Binding implementation.
The settlement bridge does not simply trust caller-supplied flags.
It verifies the relationship between:
Machine Identity
+
recipient MYT address
+
network
+
Phase 4B identity authorization
+
native MYT spend-key authorization
Only the correctly bound recipient Machine Identity can receive the corresponding local settlement observation.
Phase 4C still does NOT prove:
- current liveness
- trusted authorization time
- exclusive key control
- permanent ownership
Phase 4E does not upgrade those semantics.
Integration with Phase 4DThis is one of the most security-sensitive parts of Phase 4E.
A stored:
is NOT sufficient to create trusted settlement reputation.
The Phase 4E bridge performs fresh verification through the existing read-only payment-verification path.
During the independent release review, an internally consistent fake PAID SQLite row was deliberately constructed.
Without valid fresh native payment evidence:
no Phase 4E settlement observation was created
The verification path checks:
- proof format
- transaction
- invoice-bound message
- recipient
- network
- exact amount
- stored TXID match
- transaction not in pool
- required confirmation depth
This point is important.
MYT OutProofV2 does NOT identify the payer Machine Identity.
Therefore Phase 4E never derives:
from a payment proof alone.
Settlement attribution is only made to the correctly bound RECIPIENT Machine Identity when the cryptographic relationship supports it.
A caller cannot inject:
into the objective settlement schema.
The implementation explicitly reports that payer identity was not inferred.
Local Reputation PolicyPhase 4E includes a deterministic local reputation policy.
It may consider signals such as:
accepted issuers
attestation age
revocation state
settlement linkage
per-issuer contribution limits
The policy contains:
- no machine learning
- no hidden weights
- no remote reputation oracle
- no centralized MYT trust server
The same:
produces the same result regardless of import ordering.
The default issuer allowlist is empty.
Unknown issuers do not automatically become trusted.
Persistent ReputationStorePhase 4E includes a local SQLite-backed ReputationStore.
The store uses:
BEGIN IMMEDIATE
synchronous=FULL
trusted_schema=OFF
unique constraints
bounded storage
validated reads
Stored signed artifacts are reparsed and revalidated when snapshots are built.
Inconsistent or corrupt records fail closed.
Concurrency was tested using both threads and independent processes.
Privacy modelPhase 4E remains off-chain.
There is no protocol-level global public reputation registry.
The ReputationStore does not unnecessarily persist:
- raw transaction IDs
- full payment proofs
- recipient addresses
- invoice memo
- invoice reference
- wallet seed
- private identity keys
- RPC passwords
Settlement observations retain only the minimum local evidence required by the model.
However:
Hashing is not anonymity.Stable hashes and signed reputation artifacts can remain linkable.
This is explicitly documented.
That privacy limitation is one of the reasons the next roadmap stage exists:
Phase 4F — ZK Selective Disclosure.No automatic spendingPhase 4E does not add MYT-spending capabilities.
The settlement bridge remains read-only.
The wallet-related RPC paths used by the reputation settlement flow are limited to:
validate_address
verify
check_tx_proof
There is no new reputation path for:
transfer
sweep
wallet unlock
seed export
private-key export
Phase 4E also introduces no new production:
subprocess
shell
eval
exec
pickle
dynamic-code execution
The MYT Machine CLI now includes reputation workflows for:
attest
verify
import
get
list
summary
revoke
record-settlement
Most reputation workflows are completely offline and do not require a daemon or blockchain connection.
The existing secure Phase 4B identity-key/passphrase handling remains in place.
No new passphrase-through-command-line or environment-variable mechanism was added.
Final independent release security reviewAfter the initial Phase 4E implementation was completed, the candidate underwent a separate adversarial release security review.
The original candidate was:
9aa14e068570a086b25c68cb78f446f7d3ff2f35
That candidate was NOT released.
The review discovered two Low-severity diagnostic-redaction issues.
F-01 — Identity parser diagnosticsUntrusted Identity JSON field names could appear in normal Phase 4E CLI error output.
The fix replaces the diagnostic details with a generic validation error.
F-02 — Wallet RPC diagnostic textFree-form Wallet RPC application-error text could propagate through Phase 4E error output.
The fix retains the numeric/classified error information but removes arbitrary server-controlled text from normal user-facing diagnostics.
Three permanent regression tests were added.
The corrected and fully re-reviewed candidate became:
ff1624ff6263bfd4142550391a381f96006a0413
This is the only approved and released v0.5.0 commit.
The review found no release-blocking path within the documented threat model to:
- forge reputation for honestly generated and independently trusted issuer keys
- inflate one event through replay
- derive false payer identity
- bypass revocation authority
- turn a fake PAID database row into verified settlement reputation
- reuse one settlement as multiple objective observations
This is NOT being presented as a mathematical security proof or independent third-party cryptographic certification.
It was a separate adversarial release-security review of the implementation and its documented trust model.
Independent attack suiteA separate attack suite was created outside the tracked repository.
It did not simply reuse the assumptions of the normal Phase 4E tests.
It covered areas including:
- signature forgery attempts
- key substitution
- signed-field mutation
- signature/domain transplant
- parser corpus
- alternative encodings
- timestamp boundaries
- thread/process replay
- self-attestation
- collusion scenarios
- revocation authority
- pending revocations
- database corruption
- forged PAID state
- invalid Phase 4C bindings
- TXID substitution
- proof substitution
- payer-identity injection
- privacy/history leakage
- filesystem safety
- CLI workflows
- diagnostic redaction
- rebinding scenarios
- Ed25519 scalar malleability checks
Final independent results:
Linux:
35 / 35 passed
Windows:
34 passed
1 Unix-specific filesystem skip
The final v0.5.0 repository contains:
By roadmap phase:
4A – Machine Settlement SDK
66 / 66
4B – Agent Identity
62 / 62
4C – Signed Address Binding
47 / 47
4D – Payment Requests / Invoices / API Billing
143 / 143
4E – Agent Reputation
106 / 106
Total:
The existing 318 Phase 4A–4D regression tests remain intact.
Linux / Windows matrixThe final candidate was tested with:
Python 3.10
Python 3.12
Python 3.13
against both:
cryptography 50.0.0
cryptography 50.0.1
Linux:
6 matrix runs
424 / 424 passed in every lane
Native Windows:
6 matrix runs
415 passed
9 documented Unix-specific skips
The Windows skips concern Unix file permissions, symlinks and FIFO behavior.
Those checks pass on Linux.
No new skip rules were added merely to obtain a green result.
Security and packaging gatesThe final candidate passed:
Ruff
Bandit
compileall
pip check
pip-audit
wheel build
sdist build
twine check
installed-wheel testing
offline reputation E2E
secret/path scanning
Runtime dependency remains:
No new Phase 4E runtime dependency was added.
GitHub ActionsThe final GitHub Actions run for:
ff1624ff6263bfd4142550391a381f96006a0413
completed successfully:
The CI matrix includes Linux and Windows with Python 3.10, 3.12 and 3.13 against floor/latest cryptography versions, plus dependency-security and packaging jobs.
Official v0.5.0 release assetsThe GitHub release contains:
myt_machine_settlement-0.5.0-py3-none-any.whl
myt_machine_settlement-0.5.0.tar.gz
SHA256SUMS.txt
SHA-256:
a64ce8ae0c1aed2afa36e322ee09c836cc427e84d6131f03953090660eaaf4f9 myt_machine_settlement-0.5.0-py3-none-any.whl
3d9c76452d8c6fb23d3d79a8ea983f441003c4d54ed3eca26c5ae60a0a7088a5 myt_machine_settlement-0.5.0.tar.gz
98256257dc8d470fc5b107ef4104c4f6a763cd13a84aa61c60b85efaef98de3a SHA256SUMS.txt
The published assets were downloaded again after publication and verified against the published checksums.
Known trust and security boundariesPhase 4E deliberately does NOT claim to solve:
- global Sybil resistance
- dishonest trusted issuers
- collusion
- unique human identity
- complete reputation history
- trusted global time
- guaranteed revocation delivery
- payer identity
- service-quality proof
- host compromise
- wallet/daemon compromise
- local database compromise
- continuous chain-reorg monitoring
- disclosure linkability
Issuer trust remains an application/operator decision.
A syntactically valid public key is not automatically a trustworthy issuer.
The security review also examined attacker-selected Ed25519 public-key edge cases.
No forgery was demonstrated against normally generated and independently trusted MYT Machine identity keys.
Intentionally trusting unsafe or attacker-selected key material remains a key-provisioning/trust-boundary issue.
A separate supply-chain hardening item also remains:
GitHub Actions currently use mutable major-version Action references rather than pinning every third-party Action to a full immutable commit SHA.
This is documented rather than hidden.
No consensus changesPhase 4E changes nothing in:
MYT Core
RandomX
block validation
emission
HF17
transaction format
Wallet RPC schema
consensus
Agent Reputation remains an off-chain MYT Machine layer.
How Phase 4A through 4E fit togetherA simplified model:
4A – Settlement
Software can send and verify MYT payments.
↓
4B – Machine Identity
A machine or agent can have a cryptographic identity.
↓
4C – Signed Address Binding
A Machine Identity and MYT settlement address
can jointly authorize their relationship.
↓
4D – Payment Requests / Invoices / Billing
A service can request MYT payment and verify
settlement before providing access or work.
↓
4E – Agent Reputation
Machines can accumulate attributable signed
opinions and locally verified settlement evidence
under explicit local trust policy.
MYT Machine now has a foundation covering:
IDENTITY
+
ADDRESS BINDING
+
SETTLEMENT
+
BILLING
+
REPUTATION
The final technical milestone of the current MYT Machine roadmap is:
Phase 4F — Zero-Knowledge Selective DisclosureThe long-term goal is to allow a Machine Identity to prove selected properties about its reputation or credentials without disclosing its entire underlying history.
Today, proving reputation may require revealing attestations or other evidence.
A future Phase 4F system could allow statements conceptually similar to:
accepted_attestations >= N
verified_settlement_events >= N
local_policy_result >= threshold
without necessarily exposing:
every attestation
every issuer
every settlement observation
the exact underlying reputation data
Phase 4E deliberately did NOT implement:
SNARKs
STARKs
new Bulletproof circuits
custom commitment schemes
Merkle reputation accumulators
custom ZK cryptography
Phase 4F will be designed and reviewed separately because it is substantially more cryptographically sensitive than the previous MYT Machine phases.
Release and sourceMYT Machine v0.5.0:
https://github.com/MYT-Core/MYT-Machine/releases/tag/v0.5.0Repository:
https://github.com/MYT-Core/MYT-MachineCurrent roadmap:
4A – COMPLETE
4B – COMPLETE
4C – COMPLETE
4D – COMPLETE
4E – COMPLETE
4F – NEXT
Next milestone:
Phase 4F — Zero-Knowledge Selective DisclosureFeedback, adversarial review, testing and external integrations are welcome.
