Owners: @David Rusu @Giacomo Pasini

We’ve implemented an atomic transfer transaction, allowing a user to transfer assets from one zone to another in an atomic transaction. This report intends to give a the high-level design decisions and tradeoffs that were made.

Tracking Zone Identity Across Notes

One difficulty we ran into was how to track a zone identity as it evolves across transactions. The notes holding the zone state are destroyed each time they are consumed in a transaction and new notes are created as outputs. Moreover, zone notes are permissionless meaning we need to take into account the fact that adversaries may create notes that look like zone notes and protect against any bad behaviour resulting therein.

Upon analysis, we found there just two note fields where important to determine the behaviour of a note: 1. the note unit and 2. the note death constraint.

The death constraint controls the conditions under which a note can be spent and the unit defines the fungibility domain of the note’s value. Taken together: (unit, death_constraint) can create a stable identity of some entity across transactions.

Now, a zone is composed of a collection of different notes, but at the simplest level, we have the state note whose death constraint ensures the STF is run according to zone rules and a fund note where the locked zone funds are held.

So for this simple case, the identity of a zone is the 3-tuple:

• zone_unit The pseudorandomly generated unit of the zone state note
• state_constraint The state note death constraint concerning proper STF evaluation
• fund_constraint The fund note death constraint controlling access to zone funds.

These 3 fields control the entire behaviour of the zone and as such are sufficient for identifying zone notes. We refer to this 3-tuple as the “Zone Metadata”.

struct ZoneMetadata {
    zone_unit: Unit,
    state_constraint: DeathConstraint,
    fund_constraint: DeathConstraint,
}

We call the hash of this Zone Metadata the “Zone ID”.

If Alice wants to transfer assets from Zone A to Zone B, then she must know the ZoneMetadata for the two zones in order to be sure she will not lose her funds by being tricked into sending funds to some adversarially controlled zone. She must lock her transactions behind validations that ensure the notes receiving the deposits match the target zone’s metadata.

Ensuring Zone Identity is Stable Across Time

Given zones are evolved through permisionless transactions. We need to ensure that the zone does not become corrupted by adversarial executors omitting or changing some aspect of the zone identity (e.g. changing zone behaviour by swapping out the STF)

With the Zone Metadata abstraction from above, a stable zone identity reduces down to asserting the existence of an output note that conforms to the Zone Metadata. This is implemented in the Zone’s State death constraint which makes the following assertions:

There exists an output note out s.t.