Proxy Assets

[bmgentile]

Summary
This is a feature proposal to the Hedera Token Service that allows users to create "Proxy Assets". Proxy Assets are tokens representative of and tied to an underlying immutable digital asset (real asset). They can be configured to perform automated transaction execution on their underlying "real asset" once certain parameters are met, including parameters such as time and/or price via an on-chain oracle; additionally, both the real asset and proxy asset are linked in the historical data of a mirror node (e.g. if information about a real asset or proxy asset is queried, it should show they're linked & details). Proxy assets enable the concept of "promised value" with programmability, enabling transparent and programmable counter-party risk on-chain.

The reason / assumption for creation of proxy asset functionality is the desire by institutions and individuals to ensure that real assets on-chain remain completely immutable & decentralized, while offering greater control to the custodian or issuer of the real asset in utilizing it in a financial transaction.

Proxy Assets offer greater flexibility in meeting regulatory compliance and risk mitigation (counter-party risk, fraud, & human error) for both individuals and institutions (fintech applications, banks, etc.).

Rough Examples
In practice, here are two rough examples of how proxy assets might function & deliver value:

IPO Lockup
An initial public offering (IPO) lock-up period is a caveat outlining a period of time after a company has gone public when major shareholders are prohibited from selling their shares. During the IPO lock-up company insiders and early investors cannot sell their shares, helping to ensure an orderly IPO and not flood the market with additional shares for sale. Lock-up periods usually last between 90 to 180 days. Once the lock-up period ends, most trading restrictions are removed.

In this scenario, a proxy asset representative of the underlying "real asset" (shares) can be issued to employees, as required by law. The proxy asset is recognized by any peripheral party observing the holder's account as a deed to the underlying asset at its current price (oracle required), but prevents the holder from trading said asset before legally allowed, as it could be configured as soul-bound or recognizable by the trading platform as a "proxy asset". Further, a proxy asset could be configured to swap for the real asset after a certain time condition is met (90 - 180 days).

Security Deposit
A security deposit is money that is given to a landlord, lender, or seller of a home or apartment as proof of intent to move in and care for the domicile. Security deposits can be either be refundable or nonrefundable, depending on the terms of the transaction. A security deposit is intended as a measure of security for the recipient, and can also be used to pay for damages or lost property.

In this scenario, proxy assets representative of USDC could be issued to a landlord, lender, or seller, while the underlying USDC is retained by the holder to gain interest, be used in the valuation of the asset holder's total net worth, etc. The proxy assets could be configured to swap for the underlying real assets, burned (if no action is needed), or partially redeemed — after a certain time condition is met, such as the end of a lease agreement.

Additional thoughts
My understanding of financial scenarios in which proxy assets might be applicable is limited, but I believe there is great potential for use cases that call for proxy assets. I'm curious to get the communities' thoughts on the following:

• More financial and regulatory use cases where a proxy asset might be applicable.
• Technical implementation thoughts / ideas, specifically with regards to feasibility and configuration of parameters.

[bugbytesinc]

Smart contracts are capable enough, it would seem this is already accomplishable on the Hedera Network.

[marko-zeroproxy]

Proxy Assets are not so much a different capability than they are a different mode of building and execution.

Specifically, the key difference is that Smart Contract execution is permanent and monolithic, while Proxy Asset execution is temporary and modular.

In a typical CS Textbook, a proxy is defined as an "interface to something." Proxy assets are an interface to digital assets, enabling the proxy to take on additional properties without impacting the underlying asset.

These properties can be expressed entirely as conditions on transfers, which makes them fully composable with no need to interface with proprietary smart contract logic.

Another way to think of this is that a proxy lets you attach conditions to assets that follow those assets anywhere they go, and disappear once no longer needed.

Proxy assets accomplish this by capturing an in-between, "maybe" state as a self-expiring object.

More specifically, proxy assets let you de-compose smart contract execution into a series of temporary, conditional steps, that are themselves composable blockchain objects, rather than runtime variables acted upon by a virtual machine.

We call these Ephemeral States and they're key to what makes proxy assets special.

Ephemeral States

This is a subtle point and somewhat counterintuitive. Let me aim to illustrate with an asset vault as an example.

A smart contract would create the vault at a given address, define the rules by which assets can move in or out, and expose methods for doing so. Individual transactions, such as a deposit of 1000 HBAR, would be operations of the smart contract passing appropriate parameters to move the funds from the origin wallet to the asset vault. All transactions and funds would be managed monolithically, in aggregate, by the smart contract. All state changes would be permanent and would be managed by the underlying Layer-1 state machine. There is no possibility for creating conditions around incomplete or revocable transfers without implementing conditional logic specific to the asset vault.

An ephemeral state, by contrast, would be instantiated by a smart contract and pertain only to a single transaction. Rather than moving the funds directly, the ephemeral state would lock the asset to be moved (e.g., HBAR), issue a proxy asset reflecting the wrapped asset (e.g., “0xHBAR” in the ZeroProxy lexicon), define and embed an expiration condition, and then move the proxy asset into the vault. The 0xHBAR deposited in the asset vault would reflect an ephemeral state of the transfer, with the underlying asset and resolution conditions introspectable at any time (i.e. human-readable in text at the proxy asset address). The 0xHBAR is composable and can move and interact just as HBAR can. An escrow controller defines all conditions in terms of on-chain state, making settlement or expiration deterministic and predictable. Depending on the outcome of the conditions, the 0xHBAR state would either proceed, replacing the 0xHBAR in the vault with the HBAR locked at instantiation, or it would revert, the 0xHBAR disappearing, unlocking the original HBAR.

While this may seem a subtle distinction, it delivers several unique benefits:

1. Composable: Since the ephemeral state is atomic, it is both composable and portable, maintaining its instantiating logic and asset guarantees. Ephemeral states therefore transform individual transactions into self-contained objects that can move within and across blockchains. This allows individual transactions to be bought, sold, transferred, staked, etc. This can duplicate the architecture of traditional smart contracts, while also enabling properties traditional smart contracts cannot replicate.

2. Transparent: An ephemeral state’s conditions can be known at the time of creation, and can be publicly introspectable for its entire lifecycle. This is in contrast to the executional state of a smart contract invocation, which is often impossible to determine.

3. Recursive: Ephemeral states can be recursive, with one state wrapped in another, to any degree necessary.

4. Compartmentalized: Since an ephemeral state represents only a single transaction rather than an aggregate pool, each state wrapper must be attacked individually, making the attack surface small and highly fragmented. Since ephemeral states are transitional, should an exploit in the states be found, the exposure would be limited only to the current population of outstanding states. As ephemeral states are immutable from the time of instantiation, attacking the instantiating smart contract can impact future states, but not existing ones.

5. Modular: Since the instantiating smart contract is only creating ephemeral states rather than managing permanent ones or a matrix of conditions, the smart contract logic can be much simpler, further reducing the attack surface.

6. Registered: Ephemeral state creation can be registered, storing all active ephemeral states on the blockchain, making the overall system of ephemeral states introspectable.

Collectively, these properties establish ephemeral states as a mechanism for orchestrating a collection of transient state changes decoupled from an underlying Layer-1 state machine.

I will explain how this enables specific, unique use cases in additional posts to follow.

(FYI, I'm fully aware that Hashgraph uses a DAG data structure; using blockchain here as a generic term for a public, distributed network).

[bmgentile]

Smart contracts are capable enough, it would seem this is already accomplishable on the Hedera Network.

Appreciate the reply and was thinking that too, in that smart contracts offers huge degrees of control through their programability. However, it does require the creation and execution of smart contracts (cost, potential vulns, complexity) rather than it being baked into the API.

Are there other scenarios we can think of in which having a proxy asset might be useful? Tying on-chain (web3) and off-chain (web2) assets possibly?

[bmgentile]

@Ashe-Oro an update from the Zero Proxy team wrt a tangible example, using the format you provided.

Example 1: Protected Transactions

What I want to do
I want to be able to recover my tokens if they are stolen.

Why smart contracts aren’t enough
Once the assets leave a wallet controlled by the contract, there’s no way to touch them anymore; I need a way to embed logic in the assets themselves.

Zero Proxy solution

1. I place the underlying assets in secure cold storage, air-gapped, with keys offline.

2. An escrow controller then creates proxy assets to represent the underlying assets.

3. Each proxy asset is a unique ownership claim to the underlying asset, but not the asset itself.

4. I use the proxy asset for all other quotidian use cases - pay, trade, stake, etc.

5. The proxy assets themselves are normal tokens, so they do not require any special integration to move around the ecosystem. They do have an additional component demonstrating their unique link to the underlying assets, which can be verified via a new set of methods. This is higher-level functionality that isn’t necessary for them to function or be recognized as tokens, though.

6. If the proxy asset is ever stolen or lost, I submit evidence that this took place, and the new holder of the proxy asset has an opportunity to submit contrary evidence. This evidence is stored on-chain, and the lost/stolen assets are revoked and marked as such, and linked to the on-chain evidence. The escrow then issues a new proxy asset to me, which I can transact with as if the theft never took palace.

[Ashe-Oro]

still seems that a contract could take custody of the original token, issue a proxy token to the user which would include various parameters for how it works. The proxy token could then be wiped/frozen and managed at any time by the contract since it created the new token class. Anyone who holds the proxy asset could redeem it for the underlying at any time as long as they are within the various parameters assigned during creation. You could use HTS, ERC20 or ERC721 here.

I'm still missing where contracts fall short here.

[Ashe-Oro]

If the proxy asset is ever stolen or lost, I submit evidence that this took place, and the new holder of the proxy asset has an opportunity to submit contrary evidence.

This sounds like it contains a human element, which would be outside the scope of a the HIP. Who will make these subjective judgements of if a token was stolen and how to get it back? Check out the whole ECAF drama on EOS during 2018 for a case study on why this didn't work.

[bmgentile]

I think the thesis is that established financial institutions would want to be the arbiters of that, as they are today, while still extracting value by employing blockchain tech / infra: fast settlement, low fees, removal of *most* intermediaries, etc. Marko will need to answer. *BRADY GENTILE* DIRECTOR, PRODUCT MARKETING *SWIRLDS LABS* Cell: 480.735.1133 <4807351133> Twitter: @bmgentile <https://www.twitter.com/bmgentile> From: Ashe Oro ***@***.***> ***@***.***> Reply: hashgraph/hedera-improvement-proposal ***@***.***> ***@***.***> Date: February 8, 2023 at 12:56:56 PM To: hashgraph/hedera-improvement-proposal ***@***.***> ***@***.***> CC: brady ***@***.***> ***@***.***>, Author ***@***.***> ***@***.***> Subject: Re: [hashgraph/hedera-improvement-proposal] Proxy Assets (Discussion #630) If the proxy asset is ever stolen or lost, I submit evidence that this took

…

place, and the new holder of the proxy asset has an opportunity to submit contrary evidence. This sounds like it contains a human element, which would be outside the scope of a the HIP. Who will make these subjective judgements of if a token was stolen and how to get it back? Check out the whole ECAF drama on EOS during 2018 for a case study on why this didn't work. — Reply to this email directly, view it on GitHub <#630 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXFFURE6572EGWVR23TXODWWPM6RANCNFSM6AAAAAASMH5HI4> . You are receiving this because you authored the thread.Message ID: <hashgraph/hedera-improvement-proposal/repo-discussions/630/comments/4908057 @github.com>

[Ashe-Oro]

then they can deploy a contract and run it as a business. I still fail to grasp how this isn't already possible today.

[Ashe-Oro]

How is this any different than a standard wrapped token with the original token in custody on a contract?

[marko-zeroproxy]

Hi Folks, Apologies for the delayed reply, I was on the road last week. I guess there’s been some confusion here. Hi Ashe, all of your comments are correct. It is certainly possible to implement a proxy architecture using smart contracts - in fact, we’ve already done so on ETH and are working on porting to Hedera. Yes, it is analogous to a conditional wrapper linked to an underlying asset, with all of the wrapped conditions visible on-chain. Yes, we do intend to operate as a business, specifically, as a technology provider that delivers a proxy asset architecture and tools for using it, while the proxies themselves operate as normal blockchain objects - secure, transparent and immutable. The underlying concept is that we want to find a way to return the benefit of TradFi intermediaries to blockchain, except without the intermediaries or the opacity. So each transaction that needs to be intermediated can have specific conditions and timing for that intermediation programmed into it, and all of that programmed intermediation is transparent and immutable once instantiated. Re: ECAF and re-issuing stolen assets, Brady is correct. The goal here is for the issuer of the asset to maintain control, while publishing their decision criteria and the results of their actions on-chain. It’s not a community-driven dispute process, as ECAF attempted to be, but rather operates on the underlying assets. As far as the question “why aren’t smart contracts enough?” I understood that the idea here was that Proxy Assets can offer underlying functional value for enterprise use cases that may make them worthwhile to implement as an easily accessible primitive that plugs into a toolkit we would provide. That said, I don’t think we need to start this way. We have three customer use cases in the pipeline, one with an HBAR Foundation grant recipient: 1. For a big oil carbon trading consortium, providing fungible carbon credit tokens, while preserving a linkage between each issuance of those tokens and the individual carbon origination project data. 2. For a metaverse marketing company for major consumer brands, providing rights management for NFT creators by proxies that represent specific rights to the underlying NFTs. 3. For a DAO, providing rights management for members through proxy membership NFTs. We also had a great call with Leemon, and we feel strongly aligned with both the governance and technical direction Hedera is pursuing. That all said, it feels like the best way forward at this point is for us to look into porting our smart contracts to a Hedera testnet, and refactoring them to invoke the Hedera Token Service when creating new issuances of proxy tokens. Hopefully this helps. Thanks — Marko M. Cekic CEO & Co-Founder ZeroProxy Mobile: +1.512.431.0896 Office: +1.512.501.6949 Web: www.zeroproxy.io Please pardon typos.

…

On Feb 10, 2023, at 12:08 PM, Ashe Oro ***@***.***> wrote: How is this any different than a standard wrapped token with the original token in custody on a contract? — Reply to this email directly, view it on GitHub <#630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2LTTA74KIJX6XYOT2TTQQDWWZ7ZTANCNFSM6AAAAAASMH5HI4>. You are receiving this because you commented.