ERC-7951
Abstract
This proposal introduces an innovative token transfer processing model designed for third parties, enabling seamless use of Ethereum-based tokens (e.g., ERC-20) by non-crypto-native actors. The concept allows a third-party payment processor to initiate token transfers on behalf of another party and to cover the associated transaction (gas) fees. The main party (user) always remains the explicit owner of the tokens, which are securely held and referenced under their ownership in the smart contract.
The transfer process is two-phased:
- Initiation: The payment processor proposes a token transfer via the smart contract. This proposal is emitted as an on-chain event, including all relevant transfer details and a unique hash of the transaction (“proposal hash”).
- Approval: The authorized party (owner) reviews the proposal off-chain and, if in agreement, signs the proposal hash with their private key. This signature is sent to the payment processor, who then submits it to the smart contract. There, the contract verifies the signature and, upon approval, carries out the token transfer in the owner’s name.
To increase security and usability, each proposal includes an explicit expiration time. If the signature is not submitted and verified within the defined validity period, the proposal becomes void and the transfer cannot be executed.
To further enhance user safety, the owner is provided with a function that allows transferring all token balances directly to their own address in case the payment processor becomes unresponsive, acts improperly, or if external conditions such as transaction costs change unfavorably.
This model empowers entities to integrate blockchain-based payments into their workflows without directly holding or managing cryptocurrencies. All token movements require explicit owner approval, ensuring security and retaining full user control. The payment processor is compensated “off-chain” (e.g., in fiat currency) and is responsible for gas costs.
By removing the technical and operational burdens of crypto management from the end user, this approach facilitates broader adoption of tokenized business cases and simplifies enterprise integration.
Motivation
Adoption of blockchain-based payments and tokenized assets in enterprise and conventional business contexts is still often hindered by the need for end-users or business partners to directly manage cryptocurrencies, wallets, and on-chain transactions. For many organizations, the technical, regulatory, and operational burdens associated with self-custody and on-chain fee management present significant entry barriers.
This proposal aims to lower these barriers by introducing a model in which a trusted third-party payment processor can manage all blockchain transactions on behalf of a token owner, including paying transaction fees. The owner maintains full control and explicit on-chain ownership of the assets, and must approve all outgoing transfers cryptographically. Payment for the processor’s services (including gas reimbursement) can take place off-chain and in fiat currency, which aligns with existing financial workflows and compliance expectations.
With an explicit fallback function, owners are further protected, ensuring they can always reclaim direct control over their assets if the processor becomes unresponsive or external conditions change.
In summary, this standard facilitates broader and more secure adoption of token-based processes by offloading complexity from end-users, while preserving security, transparency, and user sovereignty.
Specification
Methods
Smart Contract that holds the assets (ITokenStorage.sol)
Transfer proposal: proposeTransaction
function proposeTransaction(address tokenAddress, uint256 amountToSent, address destinationAddress) external;
Called from the paymentProcessor/transactionProvider of the storage to initiate a token transfer. Emits a TransactionProposed event.
The parameter tokenAddress is the address of the token which should be transferred.
The parameter amountToSent is the amount which should be transferred to the desired destination address.
The parameter destinationAddress defines the receiver of the defined token.
The proposal is stored in the contract and a unique (uint256) hash is generated for it, which is used for the approval process.
Transfer completion: completeTransaction
function completeTransaction(uint256 hash, bytes memory signature) external;
Called from the paymentProcessor/transactionProvider of the storage to perform a token transfer. Emits a TransactionCompleted event.
The parameter hash is unique identifier of the transaction.
The parameter signature is a signed message which only includes the hash. This message is signed by the credentials of the owner, which are used to verify that the owner has approved the transaction.
This function includes a verification step to ensure that the signature is valid and corresponds to the owner of the tokens.
If the signature is valid, the contract executes the transfer of tokens from the smart contract to the destinationAddress specified in the proposal.
Fallback function: sendFundsToOwner
function sendFundsToOwner(address tokenAddress) external;
This function allows the owner to transfer all tokens held in the contract back to his/her own address.
This is a safety measure to ensure that the owner can reclaim their assets if the payment processor becomes unresponsive or if external conditions change unfavorably.
Emits a FallbackScenarioExecuted event.
The parameter tokenAddress is the address of the token which should be transferred to the owner.
In case this method is called, the contract will transfer all tokens of the given type to the owner address.
Verification of the signature: ‘verifySignature’
function verifySignature(
address _signer,
address tokenAddress,
uint256 amountToSent,
address destinationAddress,
bytes memory signature
) public pure returns (bool);
This function is used to verify the signature of the owner. It checks if the signature corresponds to the provided parameters and the owner’s address.
The parameter _signer is the address of the owner who signed the proposal.
The parameter tokenAddress is the address of the token which should be transferred.
The parameter amountToSent is the amount which should be transferred to the desired destination address.
The parameter destinationAddress defines the receiver of the defined token.
The parameter signature is the signed message which only includes the hash of the proposal.
This function can be called by the owner to verify the signature before forwarding it to the paymentProcessor / transactionProvider.
Also this function should be called within the completeTransaction function to ensure that the signature is valid before executing the transfer.
Summary
The interface ITokenStorage.sol:
interface ITokenStorage {
event TransactionProposed(uint256 hash);
event TransactionCompleted(uint256 hash);
event FallbackScenarioExecuted(address tokenAddress);
function proposeTransaction(address tokenAddress, uint256 amountToSent, address destinationAddress) external;
function completeTransaction(uint256 hash, bytes memory signature) external;
function sendFundsToOwner(address tokenAddress) external;
}