# Cross-Chain Ownership

#### Connecting NFTs to the real world <a href="#id-8r2yc8liui31" id="id-8r2yc8liui31"></a>

In the real world, every physical good can only exist in one place at a time, and also exists within its surroundings. While digital assets provide more freedom in how they are displayed and used, they also lose that connection to the real world. In a digital metaverse, an owner of a 3D model or an interactive experience may choose to anchor their content to a specific parcel or location in that digital world. But they cannot do the same in the most important metaverse of all, the physical one.

Individual owners may set up geofenced applications that only display content in specific areas, but this geospatial data is then isolated in that particular application, and that placement can not be shown and respected by applications and marketplaces. To make the placement of a digital asset more "real", the placement data must be stored in an easily-accessible, decentralized manner.

Further, physical goods are not simply placed in the world by themselves. When a sculpture or painting is placed in a public gallery or private home, and the owner makes choices about the lighting, the room, placards, wall color, and even other art that should be shown along with it. With digital assets, that customization is lost - an NFTd asset simply exists as itself, out of context. Instead, owners should be able to not only declare where their asset is, but also how it should be displayed. And again, this information should be published in a way that allows different parts of the metaverse to correctly display the owner's intended scene.

#### Owners must control placement <a href="#jezabufjffbx" id="jezabufjffbx"></a>

In the current world, anyone can decide where in the world any NFT appears, simply by viewing it. But in the physical world, the owner of an asset has sole discretion over where it is. In the same way, the GSR must respect ownership rights, and allow only the current owner of an asset to declare its position and scene.

**Possibility of single-chain ownership verification**

The GSR is deployed on the Polygon L2 chain for its low gas fees and high security. NFTs are also increasingly minted on Polygon, and for those assets, ownership verification could be simple. So long as the asset's smart contract conforms to the ERC 721 standard, the GSR smart contract could directly query the asset's smart contract to determine if the user requesting a placement is the current owner of that asset, and reject the placement if they are not. However this only works for a subset of assets (ERC 721/1155) on a single chain (Polygon).

**Cross-Chain ownership verification**

However, NFTs live on many chains, some with high gas fees. A simple solution would be to publish a separate GSR on every blockchain, and use direct ownership verification. However, this runs into a few problems:

1. Gas Fees. While someone may be willing to spend significant resources to acquire an NFT on a blockchain like Ethereum, the cost of then spending more to geolocate that asset may be too high to make it worth it. This issue also limits the utility of the GSR, as owners will not want to frequently pay to move assets or adjust scenes.
2. Cross-chain scenes. In the real world, you can buy assets in many ways, and display them together. In a GSR-per-chain system, it would not be possible to display an Ethereum and a Polygon asset in a single scene.
3. Support effort. A GSR-per-chain system would require consumers of GSR content to query numerous smart contracts, across blockchains they may not be familiar with, to view all the content in an area. Also, a new smart contract would have to be written for each chain, which increases the cost of supporting the chain, and the chances of bugs in those smart contracts.
4. Centralized storage. Some digital assets will not be on a blockchain at all, but in a centralized system. Owners of these assets may still want to place them in the world, but would be unable to do so in a decentralized way.

Instead, the GSR will live in a single smart contract, on a single low-cost L2 blockchain (Polygon). This solves the above problems, but brings in a new one - how does the GSR verify ownership on blockchains it cannot directly access? Or non-blockchain centralized systems? The answer, surprisingly, is: **don’t verify on-chain**.

To that end, the GSR exposes functions that allow anyone to declare a position and scene configuration for any uniquely-identifiable digital asset. That declaration is stored in the GSR, indexed under the address that is making the declaration. Then when someone wants to look up the current position of an asset, they first get its current owner from the chain the asset exists on (for an ERC 721 NFT, via the ownerOf view function), and then request the position of that asset according to the current owner. If the asset is on an EVM-compatible chain (like Ethereum), then the owner should have been able to send a placement using the same wallet on Polygon.So if the owner has declared a placement, this will be returned, and otherwise the transaction will fail. In this way, the GSR offloads the cross-chain work of verifying the current owner of the asset to the caller, avoiding the need for complex cross-chain ownership checks on-chain.

**Non-EVM Asset Ownership**

While this scheme works well across all EVM chains, where a single private key can be used to own assets on one chain and send transactions on Polygon, there’s a second step for non-EVM chains (like Tezos and Solana), and non-chain asset stores. The owner must be able to securely declare a single Polygon wallet as an alias for their non-EMV identity, and do so from the asset storage system to prove they own that identity. That way the declared alias may make placements, and off-chain systems can treat that wallet as the true owner of the asset.

To do this, each supported non-EVM chain must have a smart contract that with a function like `declareAlias(uint256 emvAddress)`, which records a single EVM address as the alias for the calling address. This may also generate an NFT to record this alias. A single identity may only declare one alias. If a remote identity could have multiple aliases, then a single owner could make multiple valid placements of a single NFT, which would break the uniqueness promise of NFTs. However a single EVM address may be the alias of multiple remote identities - otherwise an attacker could "claim" an address that they don't actually own.

For non-chain data sources, the community may choose other methods - perhaps a convention to add the target address to the user’s public profile, an API call, an oracle, or a Polygon smart contract that holds a link to an alias verification message from the owner.

In either case, when a Placement event occurs for a non-EVM asset store, the Indexer service can then check the asset store for the true owner, and then check the AliasRegistry to see if that owner can declared the publisher as an alias. If they have, then the placement can be considered valid.

**ERC 1155 NFTs**

While this structure works particularly well for single ERC 721 assets, it also supports multi-owner ERC 1155 assets. If an 1155 asset is owned by two addresses, each address may separately declare a placement of their asset.

However, for the GSR to function properly, each placement must have a unique AssetId, so there's a single true placement (based on the current owner of the asset). To allow transforming a fungible ERC1155 into a non-fungible asset, the full asset ID of the placement would be:

Copy

```
{
  chainId: uint256;
  contractAddress: address;
  tokenId: uint256;
  itemNumber: uint256;
  publisherAddress: address
}
```

So for example, if Alice and Bob both own two copies of a Sword, they may both make two placements of the Sword, one with itemNumber 1, and the other with itemNumber 2. If Bob then sells is Sword to Alice, she may make a third placement with itemNumber 3, and Bob's itemNumber 2 placement becomes invalid. The GSR SDK (described later) will facilitate encoding this data, and when a new placement occurs, checking that the itemNumber for the placement is <= the publisher's balance.
