Is documentation about supported tokens for exit format up to date?

[ssa3512]

Currently the documentation states that "At the current time, Nitro supports native (e.g. ETH) and ERC20 tokens."

go-nitro/docs/protocol-tutorial/0030-outcomes.md

Lines 11 to 13 in fe6ffa4

	!!! tip
	At the current time, Nitro supports native (e.g. ETH) and ERC20 tokens.

but it appears that exit format support for ERC721 and ERC1155 support were added here:
statechannels/exit-format#69

Can you provide clarification on if the documentation is accurate or if if should be updated to reflect support for 721/1155 tokens?

[geoknee]

Hey @ssa3512 thanks for bringing this up.

You are correct that support for more tokens was added to exit-format. However, that increased functionality was not yet bubbled up to go-nitro. You can see from the deposit function on our adjudicator:

go-nitro/nitro-protocol/contracts/MultiAssetHolder.sol

Lines 29 to 63 in 267bf7d

	/**
	* @notice Deposit ETH or erc20 tokens against a given channelId.
	* @dev Deposit ETH or erc20 tokens against a given channelId.
	* @param asset erc20 token address, or zero address to indicate ETH
	* @param channelId ChannelId to be credited.
	* @param expectedHeld The number of wei/tokens the depositor believes are _already_ escrowed against the channelId.
	* @param amount The intended number of wei/tokens to be deposited.
	*/
	function deposit(
	address asset,
	bytes32 channelId,
	uint256 expectedHeld,
	uint256 amount
	) external payable virtual override {
	require(!_isExternalDestination(channelId), 'Deposit to external destination');
	uint256 amountDeposited;
	// this allows participants to reduce the wait between deposits, while protecting them from losing funds by depositing too early. Specifically it protects against the scenario:
	// 1. Participant A deposits
	// 2. Participant B sees A's deposit, which means it is now safe for them to deposit
	// 3. Participant B submits their deposit
	// 4. The chain re-orgs, leaving B's deposit in the chain but not A's
	uint256 held = holdings[asset][channelId];
	require(held >= expectedHeld, 'holdings < expectedHeld');
	require(held < expectedHeld + amount, 'holdings already sufficient');
	// The depositor wishes to increase the holdings against channelId to amount + expectedHeld
	// The depositor need only deposit (at most) amount + (expectedHeld - holdings) (the term in parentheses is non-positive)
	amountDeposited = expectedHeld + amount - held; // strictly positive
	// require successful deposit before updating holdings (protect against reentrancy)
	if (asset == address(0)) {
	require(msg.value == amount, 'Incorrect msg.value for deposit');
	} else {
	IERC20(asset).safeTransferFrom(msg.sender, address(this), amountDeposited);
	}

This means the docs are accurate (of course we could make things clearer by heading off this question in the docs).

One thing that makes full integration of the exit-format a little awkward is that in our on chain code, we have a special escape hatch for what we call internal / external destinations:

go-nitro/nitro-protocol/contracts/MultiAssetHolder.sol

Lines 406 to 423 in 267bf7d

	/**
	* @notice Executes a single asset exit by paying out the asset and calling external contracts, as well as updating the holdings stored in this contract.
	* @dev Executes a single asset exit by paying out the asset and calling external contracts, as well as updating the holdings stored in this contract.
	* @param singleAssetExit The single asset exit to be paid out.
	*/
	function _executeSingleAssetExit(Outcome.SingleAssetExit memory singleAssetExit) internal {
	address asset = singleAssetExit.asset;
	for (uint256 j = 0; j < singleAssetExit.allocations.length; j++) {
	bytes32 destination = singleAssetExit.allocations[j].destination;
	uint256 amount = singleAssetExit.allocations[j].amount;
	if (_isExternalDestination(destination)) {
	_transferAsset(asset, _bytes32ToAddress(destination), amount);
	} else {
	holdings[asset][destination] += amount;
	}
	}
	}

So we aren't currently relying on the executeExit() function from exit-format. I think it should be possible to fix all of this -- it's not currently a priority for us, though.