Blockchain execution
52. Why does ChatterPay B2B use EIP-7702, and how does it keep the address?
EIP-7702 lets an EOA authorize a delegation indicator toward a code implementation without changing its address. ChatterPay uses that property so the address can be known and can receive funds before activating programmable logic.
The model is:
User's EOA
→ EIP-7702 authorization
→ stable ChatterPay7702Proxy
→ AccountCoreImplementation
→ enabled modulesDelegating to a small proxy avoids redelegating the EOA every time the Account Core changes. The usual evolution happens behind the proxy, under root/upgrade policies and with a controlled rollout.
53. What is the relationship between EIP-7702, Account Abstraction and ERC-4337?
They are complementary layers, not synonyms.
- EIP-7702 lets code be associated with an EOA while keeping its address.
- Account Core implements the programmable rules for validation, modules, nonces, roles and recovery.
- ERC-4337 defines an Account Abstraction mechanism based on
UserOperation, bundler andEntryPoint, with an optional paymaster for gas sponsorship.
An EIP-7702 account can operate without ERC-4337 via a direct relayer. ERC-4337 is enabled when the specific combination of account, EntryPoint, bundler, paymaster, RPC and network has been validated end to end. The paymaster decides gas sponsorship; it does not replace the account's authorization.
54. How is it avoided that a contract upgrade affects every wallet at the same time?
Implementations are deployed once per network and approved by version and code hash.
Migration happens progressively:
internal accounts
→ Partner canary
→ small batches
→ controlled expansionEach wallet's proxy points to the approved version. This allows stopping or reverting a rollout without changing the user's address or affecting every account at once.
55. How is Bitcoin integrated without forcing the EVM model?
Bitcoin uses a specific component that translates a financial intent into the network's UTXO model.
That component:
- queries UTXOs;
- selects inputs;
- estimates fees;
- calculates change;
- builds the transaction;
- requests the signature;
- broadcasts it;
- follows confirmations;
- reconciles the result.
The Partner keeps using the same user, wallet, quote and operation resources. Bitcoin's mechanics stay encapsulated inside its native integration.
56. How is Cardano incorporated without forcing the EVM model?
Cardano uses a native EUTXO-based adapter. The platform keeps TenantUser, WalletProfile, Quote, Operation, ledger, events and webhooks, but the Cardano adapter implements its own rules: keys and addresses, UTxO selection, multi-assets, minimum ada in outputs, fee, validity interval, witnesses, submission and chain observation.
Cardano does not use EIP-7702, ERC-4337 or a paymaster. Its integration must preserve its native differences instead of artificially translating them into EVM nonces or gas.
57. How are the keys of a Cardano wallet derived?
Cardano defines its own HD scheme via CIP-1852, with paths and roles specific to its key model. WalletProfile can group a Cardano account with EVM and Bitcoin accounts, but each family keeps its own key references, addresses and recovery policies.
58. Which assets can Cardano represent?
Besides ada, Cardano supports native assets on the ledger. In ChatterPay each asset is identified by canonical network metadata — not just by symbol — and the operation must reconcile inputs, outputs, quantities and fees according to EUTXO rules.
59. Is Cardano part of the public roadmap?
Yes. Cardano is explicitly included as a target family for the platform. Effective enablement of a Cardano capability happens by manifest and environment once the corresponding vertical has sufficient tests, observation and reconciliation; the public roadmap distinguishes that availability from the target architecture.
60. How are Tron and Solana incorporated?
Through native adapters with the same high-level functional contract — provision an account, obtain an address, query balance, prepare, sign, submit, observe and reconcile — while preserving their own primitives for resources, token accounts, blockhashes, finality and fees.
See Solana and Tron for each family's own model, and the Roadmap for current availability.
61. How are RPCs, indexers and observation sources selected?
The architecture separates:
- read providers;
- submission providers;
- observation providers.
A real-funds deployment must use redundant sources per network, with health checks, circuit breakers, backfill and divergence detection.
ChatterPay's observers keep checkpoints and validate finality. Provider webhooks speed up detection, but they are not the only source of truth.