ERC-8065 Update [2025.12.2] — Major Improvements to the remint Interface
We’ve updated the remint interface to make it more extensible, consistent, and aligned with future use cases.
Previous interface:
function remint(
bytes calldata proof,
bytes32 commitment,
bytes32 nullifier,
address to,
uint256 id,
uint256 amount,
bool withdrawUnderlying,
uint256 relayerFee
) external;
New interface:
/// @notice Encapsulates all data required for remint operations
/// @param commitment The commitment (Merkle root) corresponding to the provided proof
/// @param nullifiers Array of unique nullifiers used to prevent double-remint
/// @param proverData Generic data for prover
/// @param relayerData Generic data for relayer, can contain fee information. Hash is used in ZK proof.
/// @param proof Zero-knowledge proof bytes verifying ownership of the provable burn address
struct RemintData {
bytes32 commitment;
bytes32[] nullifiers;
bytes proverData;
bytes relayerData;
bytes proof;
}
/// @notice Remint ZWToken using a zero-knowledge proof to unlink the source of funds
/// @param to Recipient address that will receive the reminted ZWToken or the underlying token
/// @param id The token identifier. For fungible tokens without IDs (e.g., ERC-20), this MUST be set to `0`.
/// @param amount Amount of ZWToken burned from the provable burn address for reminting
/// @param withdrawUnderlying If true, withdraw the equivalent underlying token instead of reminting ZWToken
/// @param data Encapsulated remint data including commitment, nullifiers, proof, and relayer information
function remint(
address to,
uint256 id,
uint256 amount,
bool withdrawUnderlying,
RemintData calldata data
) external;
Key changes
- Introduced RemintData to align the remint pattern with deposit and withdraw, and avoid the “stack too deep” issue.
- Replaced relayerFee with relayerData to support generic, more flexible relayer payloads.
- Added proverData to support richer prover-side data structures.
- Replaced nullifier with an array nullifiers enabling batch remint capabilities.
Additional updates
- Renamed depositTo → deposit and withdrawTo → withdraw for a cleaner, more streamlined API, since the to parameter already captures the destination semantics.
Notably, we will soon open-source our implementation of ERC-8065, along with a PoC demonstrating our new ZWToken-unawareness workflow.