Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Daniel/leg 7 contemplating multiple blockchain networks #12

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

notdroll
Copy link
Member

updated trust agreement to contemplate multiple blockchain networks, either minting via or bridging to. most of the work was done in the definitions to keep the rest of the agreement stable as possible. it feels like this update added some "noise" to the agreement, so curious to hear your feedback @fedepo

updated trust agreement to contemplate multiple blockchain networks either via wrapping or minting on a different chain
Copy link

linear bot commented Apr 16, 2024

@notdroll notdroll assigned notdroll and fedepo and unassigned notdroll Apr 16, 2024
Copy link
Member

@fedepo fedepo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! It opens up the trust nicely to other networks/bridging without getting lost in the details.

I left a few notes on things you @daniel-fabrica might want to review, some not related to the multi chain setup.

2. On creation, the Trust will take and hold title to the Property, and ownership of the Trust will be represented by ownership of the NFT. Regardless of the sale, hypothecation, or other transfer of the NFT, title to the Property will remain in the Trust until such time as the then-present Beneficiary (or another authorized party) distributes the property out of the Trust. In order to facilitate the Trust Purpose, the Trustee and Beneficiary agree that no deed or other agreement transferring the Property out of the Trust will be valid unless the Beneficiary has first ensured that the NFT has been successfully destroyed (Burned).
3. Subject to **Sections 6 and 7**, the owner(s) of the Account holding the NFT shall be the Beneficiary of the Trust, and have the right to appoint the Trustee. All rights and obligations in this agreement shall at all times be linked to the owner of the NFT, such that rightful possession of the NFT gives the holder full and total beneficial ownership.
1. The purpose of the Trust is to create a legally enforceable link such that ownership of the Fabrica NFT determines ownership of the property, so as to allow for the time efficient, cost effective, accurate, and secure ownership, transfer, use and enjoyment of real property title in the digital environment (the "**Trust Purpose**").
2. On creation, the Trust will take and hold title to the Property, and ownership of the Trust will be represented by ownership of the Fabrica NFT. Regardless of the sale, hypothecation, or other transfer of the Fabrica NFT, title to the Property will remain in the Trust until such time as the then-present Beneficiary (or another authorized party) distributes the property out of the Trust. In order to facilitate the Trust Purpose, the Trustee and Beneficiary agree that no deed or other agreement transferring the Property out of the Trust will be valid unless the Beneficiary has first ensured that the Fabrica NFT has been successfully locked or destroyed (Burned).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer NFT to Fabrica NFT (everywhere in the agreement), especially since we're about to open source it

@@ -1,44 +1,45 @@
# Fabrica Trust Agreement

This Trust Agreement (this "**Agreement**") is entered into by the Grantor through the creation of a Fabrica NFT. The identifying information of this trust (the "**Trust**") may be found in the Fabrica NFT to which this Agreement is attached.
This Trust Agreement (this "**Agreement**") is entered into by the Grantor through the Minting of a Fabrica NFT. The identifying information of this trust (the "**Trust**") may be found in the Fabrica NFT to which this Agreement is attached.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minting is more specific, but we want the trust to be up and running prior to the minting onchain, since the process is:

  1. initiate the trust [by determining the tokenId]
  2. grant the property
  3. mint the token(s)

creation is a bit vague but it's still fine in this section, while minting would be incorrect.

20. **Trust Name** means the name of the Trust, more particularly defined in the NFT Metadata (in `definition.holdingEntity`).
2. **Address** means a public key address on a Blockchain Network.
3. **Beneficiary** means the individual or entity that is in control of the most recent Account owning the Fabrica NFT. In the event the Fabrica NFT has not yet been minted, or has been minted but has never yet been owned by any Account, the Beneficiary shall be the original Grantor. In the event ownership of the Fabrica NFT is fractionalized (as discussed further in **Sections 6.1. and 7.3.**), then the defined term Beneficiary as used in this Agreement shall apply to the various owners of the Fabrica NFT as a group.
4. **Blockchain Network** means the blockchain network and the consensus blockchain for such network used to maintain records of ownership and management of the Fabrica NFT to which this Agreement is attached. While the Blockchain Network is initially assumed to be Ethereum, the Blockchain Network may change due to actions of the Beneficiary, including the wrapping of the NFT to a different blockchain network or the minting of the NFT on a different blockchain network.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the assumption of Ethereum mainnet should be explicit.
We'll probably soon be minting straight to Base or some other L2 (much easier than on-ramping on mainnet and then bridging somewhere else) as you explicitly say at the end of the paragraph... so better to remove the mainnet assumption all together.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok - just as an fyi my thinking here was to give the agreement a default in the event that some terms later in the agreement fit specifically to Ethereum.

i've reviewed the agreement and think i've specified the few areas where this seems relevant, so I can just incorporate disclaimers about alternative blockchains in those areas in the new pr.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

meanwhile I'm leaning more and more toward migrating all Fabrica properties to Base, so Ethereum might not be the best "default" case.
Regardless we want this agreement to be as generic as possible so that other projects can use it on any blockchains of their choice, so we shouldn't imply any default network.

2. **Address** means a public key address on a Blockchain Network.
3. **Beneficiary** means the individual or entity that is in control of the most recent Account owning the Fabrica NFT. In the event the Fabrica NFT has not yet been minted, or has been minted but has never yet been owned by any Account, the Beneficiary shall be the original Grantor. In the event ownership of the Fabrica NFT is fractionalized (as discussed further in **Sections 6.1. and 7.3.**), then the defined term Beneficiary as used in this Agreement shall apply to the various owners of the Fabrica NFT as a group.
4. **Blockchain Network** means the blockchain network and the consensus blockchain for such network used to maintain records of ownership and management of the Fabrica NFT to which this Agreement is attached. While the Blockchain Network is initially assumed to be Ethereum, the Blockchain Network may change due to actions of the Beneficiary, including the wrapping of the NFT to a different blockchain network or the minting of the NFT on a different blockchain network.
5. **Burn** is the result of a Confirmed Transaction of the `burn` or `burnBatch` functions on the Fabrica Smart Contract that results in the removal of the association between a Token ID and an Address, effectively locking the Fabrica NFT. In the event the Fabrica NFT has been wrapped, or transferred, to an alternative Blockchain Network, it may be required to unwrap, or transfer back, the Fabrica NFT to the original Blockchain Network to Burn the Fabrica NFT. In the event that the Fabrica NFT was first Minted on an alternative Blockchain Network, the function name or process may be different, but Burning such token shall refer to effectively locking the Fabrica NFT so that it becomes untransferrable forever into the future.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to rename all instances of Fabrica Smart Contract to Token Smart Contract.

connectors/us/us-trust-agreement.md Show resolved Hide resolved
15. **NFT Metadata** means the data directly stored within the Fabrica NFT as well as external data stored on IPFS and linked within the Fabrica NFT itself (using the fields `definition` and `configuration`). On Ethereum, such Metadata will always include Token ID, Trust Name (stored as `definition.holdingEntity`), and Property legal description (`definition.claim`). Other additional information may be included to simplify property identification, verify past ownership and other activities. Alternative Blockchain Networks may utilize different data configurations or definitions.
16. **Property** is the bundle of rights identified in the legal description stored in the NFT Metadata under the field `definition.claim`. The Property so described is the bundle of rights which is to be deeded into the Trust and held throughout the life of the Trust.
17. **Smart Contract** means the bytecode deployed on a specific Blockchain Network Address which acts as a program to execute and run a series of processes or interactions.
18. **Token ID** means the unique and immutable identifier determined on Trust creation and assigned to the corresponding Fabrica NFT. The Token ID is created based on the digital signature of mutiple fields combined, including this Agreement.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

including this Agreement -> including the content of this Agreement, such as that the generation of a specific token ID also acts as a cryptographical proof of the acceptance of this exact agreement.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think this relates to the conversation about the change from "creation of the tokenID" --> "Minting of a token."

i'm trying to get comfortable with the idea that creation of the tokenID can act as a signature of this agreement and not seeing it yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the tokenID is basically an electronic signature. the specific tokenid can only be generated by the person minting the token, providing the input params described above, including the operating agreement.

In other words: a tokenId can only be generated [by the on-ramper] by picking an operating agreement.
So the tokenid is by all means a verifiable signature of the operating agreement.

I know it's a bit complex, but the key point here is that the tokenId is a cryptographically proof that the signer has elected to use a specific operating agreement.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok so we have "proof" of signature, but i think what i'm missing is intent. digital signatures can come in a lot of forms, but by my understanding the user isn't currently acknowledging their signature through creation of the tokenID

connectors/us/us-trust-agreement.md Show resolved Hide resolved
connectors/us/us-trust-agreement.md Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants