This file keeps the personal brand and flagship projects coherent across GitHub, search engines, AI assistants, email, LinkedIn, X, Telegram, Dev.to, Indie Hackers, Peerlist, grant applications, and partner conversations.

Aleksei Safonov is an independent Smart Contract QA and AI Agent Verification Engineer focused on FinTech reliability, agentic payments, state-transition safety, and reproducible evidence.

Алексей Сафонов — независимый QA-инженер по смарт-контрактам и верификации AI-агентов. Проверяет финансовые переходы, agentic payments, идемпотентность, конкуренцию, причинность и доказательства результата.

I pressure-test the moment software moves money or claims a real-world result.

One critical workflow → bounded adversarial tests → reproducible evidence → a clear ship / fix / stop decision.

When a payment, settlement, or agent action retries, races, or recovers from stale state, can the team still prove that exactly one correct outcome happened?

Use one umbrella brand and four clear product doors.

Keywords must appear naturally in titles, opening paragraphs, headings, repository descriptions, docs, article titles, and anchor text. Do not create hidden keyword lists or repetitive keyword stuffing.

Primary:

• Aleksei Safonov
• smart contract QA engineer
• AI agent verification engineer
• FinTech reliability engineer
• independent QA engineer

Secondary:

• Web3 QA
• DeFi testing
• payment systems testing
• agentic payments security
• financial state-machine testing
• API and integration testing
• independent verification

Primary:

• smart contract QA
• smart contract testing
• state transition testing
• Solidity testing
• Foundry invariant testing

Secondary:

• escrow testing
• value conservation invariant
• settlement testing
• vesting testing
• payout reconciliation
• idempotency testing
• concurrency testing
• temporal boundary testing
• reproducible security evidence

Primary:

• AI agent verification
• action receipts
• deterministic replay
• AI agent audit trail
• state transition protocol

Secondary:

• evidence completeness
• selective omission
• capture completeness
• signed action receipts
• causal trace validation
• agent result verification
• interoperability testing

Primary:

• AI agent security
• AI agent authorization
• agentic payment security
• verifiable intent
• pre-execution gateway

Secondary:

• runtime action governance
• replay protection
• human approval
• policy engine
• causal authorization
• agent payment guard
• evidence bundle

Primary:

• AI agent audit
• causal lineage
• approval lineage
• agent memory safety
• causal audit trail

Secondary:

• tool-call audit
• human-in-the-loop evidence
• responsibility lineage
• missing parent cause
• agent trace verification
• MCP audit server

Primary:

• agentic AI safety
• agentic payments
• AI reliability research
• AI agent failure modes
• evidence-first technology journal

Secondary:

• autonomous agent governance
• payment reconciliation
• idempotency
• AI action verification
• trust infrastructure
• verified reports

Smart Contract QA & AI Agent Verification Engineer · FinTech reliability

Independent Smart Contract QA and AI Agent Verification Engineer. I test agentic payments, state transitions, retries, concurrency, and evidence.

Aleksei Safonov is an independent Smart Contract QA and AI Agent Verification Engineer with 6+ years of commercial manual QA in FinTech and earlier SQL-engineering work in banking. He pressure-tests escrow, payouts, agentic payments, retries, authorization, reconciliation, and evidence.

Независимый QA-инженер по смарт-контрактам и AI-агентам. Проверяю платежи, escrow, settlement, идемпотентность, конкуренцию и доказательства результата.

Aleksei Safonov is an independent QA engineer and open-source researcher working on verifiable state transitions for smart contracts, payment systems, and AI agents. His projects include ContractGraph-QA, T-Trace/OpenPoC, ProofPath, Causal-Memory-Layer, and the RESONANCE evidence-first journal.

Causal-temporal smart-contract QA for finding reachable economic failures and producing independently verifiable evidence bundles.

An open protocol and executable benchmark for AI-agent action receipts, deterministic replay, and assurance-boundary verification.

A defensive pre-execution gateway that verifies exact intent, authority, policy, replay state, and evidence before an AI-agent action can execute.

An open-source causal audit layer that checks why an AI-agent action was allowed by validating task, delegation, policy, and approval lineage.

An evidence-first journal connecting agentic AI research, executable verification, market questions, and product signals.

Use concise descriptions; GitHub repository descriptions are not mini-READMEs.

Description

Smart-contract QA for state transitions, invariants, retries, concurrency, settlement, and reproducible evidence.

Topics

smart-contract-testing, smart-contract-security, solidity, foundry, web3, defi, qa, invariant-testing, state-machine, property-based-testing, escrow, payments, idempotency, concurrency, fintech

Description

AI-agent action receipts, deterministic replay, causal trace validation, and executable assurance-boundary tests.

Topics

ai-agent-verification, ai-safety, action-receipts, audit-trail, deterministic-replay, causal-tracing, agent-security, jsonl, protocol, interoperability, provenance, open-source

Description

Pre-execution security gateway for AI-agent authorization, agentic payments, verifiable intent, replay protection, and audit evidence.

Topics

ai-agent-security, agentic-payments, verifiable-intent, action-governance, authorization, policy-engine, replay-protection, human-in-the-loop, api-security, audit-log, zero-trust, rust

Description

Causal audit and approval-lineage verification for AI-agent actions, tool calls, memory, and high-trust automation.

Topics

ai-agent-audit, causal-lineage, approval-lineage, agent-memory, ai-safety, audit-trail, mcp, tool-calling, human-in-the-loop, observability, python, open-source

Description

Evidence-first journal and executable research lab for agentic AI safety, payments, reliability, and verification.

Topics

agentic-ai, ai-safety, agentic-payments, ai-reliability, ai-agents, verification, idempotency, payment-systems, research, technical-writing, open-source

Publish from evidence already created. One technical artifact should generate several distribution assets.

Format:

1. What the system promised.
2. The smallest adversarial sequence.
3. What actually happened.
4. The invariant that failed.
5. The reusable lesson.

Examples:

• A valid retry became a second payment because no idempotency contract existed.
• Disputed held funds but had no transition to release or refund.
• Natural settlement accrued past the configured end time.
• A valid trace passed while the real effect bypassed the recorder.

Format:

RED: exact failing test
FIX: narrow remediation
GREEN: regression evidence
BOUNDARY: what remains unproven

Take a common claim and tighten it.

Examples:

• “The transaction succeeded” → Which ledger, observer, and finality boundary proved it?
• “The signature is valid” → Is the authority still current?
• “The trace is complete” → What prevented bypass?
• “The retry is safe” → What identifies the same logical operation?

Ask one concrete question that a founder or engineer can answer from experience.

Examples:

• What is your source of truth after a payment timeout?
• Can dispute and release both be valid from the same state?
• What evidence must exist before an AI agent may spend money?

Publish:

• a new executable vector;
• an external reproduction;
• a corrected claim;
• a boundary discovered during testing;
• a small before/after diagram;
• a call for a second independent implementation.

artifact
  ↓
GitHub proof
  ↓
RESONANCE article or verified report
  ↓
LinkedIn / X / Telegram post
  ↓
question to practitioners
  ↓
reply thread
  ↓
fixed-scope pilot
  ↓
public non-sensitive result

Preferred channels:

1. GitHub — canonical technical evidence.
2. RESONANCE — canonical readable explanation and SEO page.
3. LinkedIn — professional story, lesson, and conversation.
4. X — compressed claim, proof, and question.
5. Telegram — warm communities and concise Russian-language summaries.
6. Dev.to / Hashnode / Indie Hackers / Peerlist — adapted distribution, always linking back to the canonical page.

A sustainable cadence is more valuable than a burst followed by silence.

I work on one narrow but expensive boundary: the moment software moves money or claims a real-world result.

A payout can time out and retry. Two valid transactions can race. A contract can enter a value-holding dead end. An AI agent can present a valid-looking trace that does not prove the effect it claims.

I independently pressure-test those transitions across smart contracts, payment systems, and AI-agent workflows.

My method is simple:

one critical workflow → bounded adversarial tests → reproducible evidence → regression coverage → a clear ship / fix / stop decision.

Current open-source work: • ContractGraph-QA — state-transition and invariant testing for contracts • T-Trace/OpenPoC — action receipts and assurance boundaries • ProofPath — pre-execution authorization for agent actions • Causal-Memory-Layer — causal and approval-lineage audit

I am open to paid, fixed-scope reviews. The best first message is one question: What is the single transition your team cannot afford to get wrong?

I pressure-test the moment software moves money or claims a real-world result.

Smart-contract QA • AI-agent verification • agentic payments • retries • concurrency • reconciliation • evidence

One risky transition → reproducible proof → ship / fix / stop.

github.com/safal207

Я Алексей Сафонов, независимый QA-инженер по смарт-контрактам, платежным системам и AI-агентам. Проверяю не только отдельные функции, а целые финансовые переходы: escrow, payout, dispute, settlement, retry, concurrency и reconciliation. Результат — воспроизводимый тест, точная трасса и понятное решение: выпускать, исправлять или остановить.

The contract call was valid. The economic outcome was not.

Promise: [business promise].

Minimal path: [actor → action → state → action].

Observed result: [exact result].

Broken invariant: [invariant].

Fix: [narrow remediation].

Regression proof: [test/CI link].

Boundary: [what this does not prove].

Question: How does your system handle this boundary?

A valid trace is not automatically proof of complete execution.

In this fixture:

• the presented records validate;
• the real effect occurs outside the recorder;
• structural validity stays true;
• capture completeness becomes insufficient.

The lesson: integrity of recorded evidence and completeness of real-world capture are separate claims.

Reproducible artifact: [link].

I shipped [feature/vector/version].

It can now: [specific capability].

It still cannot prove: [explicit boundary].

The fastest reproduction is: [command].

I am looking for: [second implementation / design partner / review].

I am opening one fixed-scope verification slot for a team with a high-risk [escrow/payment/agent-action] workflow.

Best fit: [workflow].

Pressure cases: [three cases].

Deliverable: reproducible traces, risk classification, and regression coverage.

No broad production access required.

Reply with the one transition you cannot afford to get wrong.

Do not ask a cold audience to buy before they understand the problem.

1. Low friction: “Does your system have this boundary?”
2. Evidence: “Run the fixture / inspect the report.”
3. Conversation: “Describe the one workflow you cannot afford to get wrong.”
4. Pilot: “Agree one bounded test surface, fee, and deliverable.”
5. Expansion: “Only expand after the first result is useful.”

Use two to four relevant hashtags, not a cloud.

Commercial smart-contract content:

#SmartContracts #Web3QA #DeFi #SoftwareTesting

Agent verification content:

#AIAgents #AISafety #AgentSecurity #AIEngineering

FinTech reliability content:

#FinTech #Payments #ReliabilityEngineering #QualityAssurance

Canonical URLs should point to GitHub evidence or the matching RESONANCE article.

Recommended campaign names:

utm_source=linkedin|x|telegram|devto|peerlist
utm_medium=social
utm_campaign=project-topic-yyyy-mm
utm_content=hook-or-format

Example:

https://safal207.github.io/RESONANCE/before-you-let-an-ai-agent-move-money.html?utm_source=linkedin&utm_medium=social&utm_campaign=agentic-payments-2026-08&utm_content=timeout-retry-hook

Always separate:

• completed paid work;
• mutually signed-off work;
• independent interoperability;
• merged contribution;
• acknowledged conversation;
• pilot under review;
• unanswered outreach.

Never turn a logo, reply, test vector, or GitHub interaction into a broader partnership claim than the evidence supports.

Use this structure:

Observed: what happened.
Verified: what was independently checked.
Inference: what the result suggests.
Not claimed: what remains unproven.

1. Publish one canonical personal positioning page and keep wording stable.
2. Give each flagship repository one search intent, one opening promise, one quickstart, and one shareable proof.
3. Add repository descriptions, topics, and social-preview images in GitHub Settings.
4. Publish one RESONANCE article per flagship keyword cluster.
5. Repurpose each article into one LinkedIn post, one X thread, and one Telegram summary.
6. End every asset with one concrete question, not a generic “thoughts?”
7. Track which questions produce qualified technical replies and pilot conversations.