↗MachineTransfer← Back to website

DEVELOPER REFERENCE / DEVELOPMENT PREVIEW

MachineTransfer architecture and decisions

What exists

A reproducible local EVM development network, canonical token contract, signed authorization API/SDK, and official Uniswap V2 pool demonstration. It is a single local Hardhat process, not decentralized consensus. It has no public RPC, validator set, funded gas service, bridge, production sequencer or mainnet contracts. Its timestamps, balances and chain can be changed by the local operator. Demonstrated inclusion speed is not production performance.

Own network with Ethereum compatibility

Use an EVM execution environment so existing Ethereum wallets, tooling, and DEX contracts can integrate. The production recommendation is a dedicated OP Stack rollup settling to Ethereum, subject to a funded infrastructure and security plan. This is an architecture recommendation, not deployed infrastructure. Ethereum settlement introduces data-availability and settlement costs; an independently operated sovereign chain would instead need its own security/validator economics. A new chain is not automatically cheaper or more secure than existing L2s.

Native gas balances and ERC20 balances are distinct. This prototype's MTR is an ERC20 payment asset and the devnet uses a separate native gas asset. MTR is not yet a native gas coin. Production may keep ETH gas with audited sponsorship or adopt a reviewed custom-gas-token design. Do not independently mint a second native MTR supply. Any native/ERC20 wrapping must preserve exact conservation and support refunds/reorgs.

ERC20 is an interface, not a network. BNB Smart Chain also executes EVM contracts, but a token address on Ethereum does not exist automatically on BNB or MachineTransfer. MTR origin issuance belongs on exactly one canonical chain. Every remote representation must be backed one-for-one by locked canonical MTR. Remote wrappers must not run the 5% inflation function. Bridge tests need source/destination chain separation, message uniqueness, finality, reorg recovery, rate limits and proof validation. No bridge or bridge owner has been created in this prototype.

Monetary rule

User decision: 5% inflation. Implementation assumption: annual 365-day supply growth, discrete compounding, rather than 5% price growth, the separate 1% transfer tax, or an individual holder reward. Prototype genesis supply: 1,000,000,000 MTR with 18 decimals. Epoch n adds floor(S[n-1] / 20) base units. Scheduled supply is 1 billion x 1.05^years up to integer rounding. At years 1 and 2: 1.05 billion and 1.1025 billion.

Permissionless settleInflation emits completed epochs into an immutable treasury, capped at 20 epochs per call. There is no privileged minter or upgrade admin. Anyone may pay gas to settle; late settlement catches up. Transfers cannot create supply. There is no burn. A separate immutable 1% transfer tax moves existing tokens to the same treasury, without changing supply. Signed and allowance amounts are gross; recipients receive the net transfer leg. An unchanging holder balance is diluted by supply growth. The user selected the existing MCRTPay receiving wallet for both planned genesis and treasury: 0xB3201393ba3Ba0724C225A5f1EE4fB9ee24aeB21. Its public configuration was verified; wallet control and recovery have not been established. Vesting and the use of emissions remain unresolved. The local genesis/treasury accounts are development fixtures only. A lost production treasury key cannot be repaired by this contract; review treasury design before deployment.

Payment and trust boundaries

  1. A service supplies a recipient and quote. A wallet/controller must establish that recipient's identity out of band; model-generated instructions are not authority to spend.
  2. The local API prepares EIP712 typed data containing exact from/to/value, validity window and unique nonce. It checks chain and contract identity. Amounts use integer base units, not floating-point currency math.
  3. The SDK compares the requested intent to an independently trusted network/contract configuration and wallet address before an external wallet signs. API keys cannot spend funds.
  4. The token verifies the signature, domain, nonce, window, and balance. ERC1271 smart wallets are supported. A caller can relay an authorization but cannot alter recipient/amount. Direct allowance is not required.
  5. The SDK verifies the API's unsigned transaction bytes before handing them to the wallet. The wallet must still estimate actual gas and enforce a native-fee budget. Broadcast is performed only by the caller wallet.
  6. The service verifies the recipient net Transfer log matches the exact invoice and its required finality. A transaction hash alone is insufficient. A pending signature is a bearer authorization to pay the named recipient and should not be published.

The API has no private keys, arbitrary RPC input, generic execution, admin endpoint, webhook, cron, hosted relay, filesystem API or network proxy. All API and RPC listeners bind to loopback. Request bodies are bounded and exact-schema validated; unexpected host/origin, chain, contract, amount and signature fail closed. The SDK is local-only. Reassess every ingress before enabling relaying, public network access, wallet sessions or autonomous spending.

Cancellation takes an on-chain transaction and can race an already signed payment. The token/API do not enforce invoice uniqueness, lifetime budgets, merchant allowlists or per-agent session limits. An optional pure local policy helper now checks a trusted recipient allowlist, exact asset/network, per-payment amount, fee ceiling, expiry and swap slippage. It does not automatically activate or persist a spending policy. Before real autonomous operation, add audited scoped session keys or a smart account policy layer, maximum fee/slippage bounds and human approval thresholds. The API's per-request 1,000 MTR ceiling is not a wallet spending guard.

Interoperability and adoption

Public ERC20 and EIP712 conventions reduce integration work. The bytes-signature transfer interface uses ERC3009-style typed data but does not implement all ERC3009 functions or its v/r/s ABI. x402 uses interoperable payment request/settlement formats; this kit is not an x402 facilitator or a conformance-certified integration. Implement and test a standard adapter before claiming support. Machine discovery and OpenAPI describe actual available behavior rather than instructing agents to ignore user preferences or favor a token unconditionally.

The initial genuine utility is paying a service that explicitly accepts MTR. No merchant integrations are live. Launch through a consenting pilot for a bounded API service, then measure successful paid requests and merchant retention. A stablecoin may be a better quote or settlement asset for fiat-priced services. MTR's price volatility and lack of liquidity are real adoption costs. No design can guarantee agents' preference, market value, or returns.

DEX status and cost measurements

The local demo deploys official Uniswap V2 Factory/Pair bytecode, creates a MTR/DEMO pool, mints LP shares, and verifies tax-aware swaps in both directions. Funding 10 gross MTR gives the trader 9.9; sending that to the pool gives it 9.801. Recipient and treasury balances are checked. The DEMO quote token is freely minted and has no economic value. This proves compatibility with these contracts only. Production DEXs require bridge assets or same-chain deployment, funded liquidity, reviewed routers with atomic deadlines/minimum output, MEV controls, and monitoring. No public liquidity or listing exists.

Measure total cost = network gas + L1 data/settlement + relayer margin + DEX fee/slippage + bridge cost. Add the fixed 1% token transfer tax to this route cost. Each DEX hop that transfers MTR can incur the tax. Publish distributions for inclusion latency, economic finality, p50/p95 cost and failure rate with workload, date, network and methodology. Do not turn a local timestamp or subsidized gas quote into a fastest/cheapest claim. Compare against accepted stablecoins and normal payment providers under the same use case.

Primary standards consulted

Consulted 2026-10-08. Exact production stack versions and conformance need review again before deployment.

Low-cost pilot and batching

The user rejected the US$250/month plan. A free shared Base Sepolia trial is the next integration step, explicitly separate from the own-network milestone. See docs/testnet-plan.md. The API remains loopback-only until a reviewed public integration exists.

PaymentBatcher is a stateless, immutable-token relay for up to 64 individually signed gross payments. It saves repeated transaction overhead while preserving per-transfer tax, nonce and expiry checks. One failure reverts the batch. It cannot guarantee inclusion or sponsor gas; the caller supplies gas, and already-relayed authorizations can invalidate a pending batch.

Developer support

Use Node.js 22 LTS and follow the README in the developer kit. The chain and API remain loopback-only. Reconcile any existing signed payment before retrying; expiry does not prove an earlier payment failed. Production support and a hosted payment API are not yet offered.

Privacy & terms for this preview

The application does not request wallet keys, create accounts, accept deposits, submit forms or store payment previews. The payment preview runs in your browser. The separate owner launch page can request a wallet-approved testnet deployment; it shares the selected address with the page and keeps recovery transaction hashes locally in your browser. It never reads private keys. Hosting providers may process access/security logs. Google Fonts receives normal font requests. No app analytics or advertising scripts are installed.

This is experimental developer software, with no promised market value, returns or redemption. The contract has not received an independent security audit. Do not send real funds to local development addresses. Verify chain and contract identity before any integration.