0xf7396c70…bde5sent to0xe5dde1cc…25e1·#10,476,958·0x1da7794d…cd477c
!smokesignal{"m":"Hello from the Foundry Treasury!\n\n# An Exploration of Ethereum Contracts as Reputational Agents\n\nTo SmokeSignal, the user's Ethereum address (in the case of this post, the Forwarder/Treasury smart contract) is the identity. This could be a DAO, a multisig, a script, or anything else capable of sending a valid Ethereum transaction to the SmokeSignal contract.\n\nThis is in contrast to a traditional system like Twitter, in which a \"company account\" must ultimately be controlled by someone who has the right username/password combo.\n\nIf you're reading this on [SmokeSignal](foundrydao.com/smokesignal/), The phace to the left of this message is not Logan's phace, and not Schalk's phace. It is, irreducibly, *the phace of the Foundry Treasury*--currently controlled by the Team Toast Multisig, but eventually controlled by Foundry Governance.\n\n---\n\nGiven that no one directly owns this Treasury in (say) a MetaMask wallet, how do we actually go about using SmokeSignal as the Foundry Treasury? If you're interested in how Ethereum smart contracts can be \"stacked\" like financial legos, read on. Otherwise, feel free to skip to the last section.\n\n### How we are posting this message today\n\nToday, Team Toast has a multisig which is the owner of the Foundry Treasury, and we want the Treasury to post to SmokeSignal. So there are three contracts involved, which all have to talk to each other. Let's visualize the operations that must all work as stacked on top of each other--the bottom of the stack representing the final desired action, and the top representing what we, as Team Toast, can directly control.\n\n1. A member of the **Team Toast Multisig** suggests a transaction...\n\n2. ... for the **Foundry Treasury** to submit a transaction...\n\n3. ... to post a message to **SmokeSignal** with a given topic and some DAI burned.\n\nThis all must be packaged or rolled up into a single transaction, so that it can be proposed in the multisig. To do this, we start from the bottom and successively \"wrap\" each action in the next.\n\n#### Construct the Core Payload\n\nStarting at the bottom, we generate the transaction payload for this SmokeSignal post. I'm drafting this in the [SmokeSignal app](foundrydao.com/smokesignal/), which firstly allows me to preview the markdown formatting. But more importantly, when I'm finished and click \"GO\" in SmokeSignal, this interface constructs the underlying `burnMessage` command for the [SmokeSignal contract](https://github.com/coinop-logan/SmokeSignal/blob/master/smart-contracts/SmokeSig/contracts/SmokeSignal.sol), and sends it to Metamask.\n\nMetamask assumes we want to sign and broadcast this immediately, but that's not what we want to do--that would post this message successfully, but the author would just be my own personal Metamask account. So instead of signing the transaction, I click on the \"data\" tab and save the chunk of data shown, then reject the transaction.\n\nWe can call this saved data chunk the **core payload**. It's nothing more than an encoded instruction to SmokeSignal to post this message, which no one has yet signed (and therefore, has no author).\n\n#### Construct the Meta-Payload\n\nWe want the author to be the Foundry Treasury, which is a [Forwarder contract](https://github.com/team-toast/Foundry/blob/master/smart-contracts/bucket-sale/contracts/Forwarder.sol). To do this, we use the Forwarder's `forward` method with `_data` set to the **core payload** and `_to` set to the SmokeSignal contract address. This **meta-payload** is essentially an instruction that says to the Forwarder/Treasury \"send this **core payload** to the SmokeSignal contract.\"\n\nThe SmokeSignal contract will see the Forwarder as the author, as that is where the transaction came from (for the Solidity devs, Forwarder will be `msg.sender`).\n\nThe incredibly flexible justsmartcontracts.dev allows us to easily encode this new transaction and grab this new data, which we can call the **meta-payload**. It's an instruction, meant for the Forwarder, to send the **core payload** to SmokeSignal.\n\nOkay, one more meta step.\n\n#### Prepare the Final Payload\n\nThe Forwarder's owner (the only agent capable of making the Forwarder do anything) is the Team Toast Multisig, a [Gnosis Multisig Contract](https://github.com/gnosis/MultiSigWallet/blob/master/contracts/MultiSigWallet.sol). The final step is to use this contract's `submitTransaction` method, which operates very similarly to the Forwarder's `forward` method used in the last step--it takes a `data` payload, and a `destination` address that the payload is to be sent to.\n\nIn this case, again using justsmartcontracts.dev to construct the transaction, we set `data` to the **meta-payload**, and `destination` to the address of the Treasury/Forwarder. This yields a third and final chunk of data, which we could call this the **final payload**. It essentially says \"Create a proposal to send the **meta-payload** to the Treasury/Forwarder\".\n\n#### Sign/Submit the Final Payload\n\nOn this final step, we don't need to extract the data for use elsewhere--we can simply (finally!) sign the thing in Metamask, as one of the owners of the multisig. This submits to the multisig a proposal to execute **meta-payload** (tell the Forwarder/Treasury to send SmokeSignal the **core payload** (post this message with some topic and some DAI burned.))\n\n(I've never before felt so shameless about nesting parentheses.)\n\njustsmartcontracts.dev submits this payload to Metamask, which signs the transaction as a member of the Team Toast Multisig. This transaction is broadcasted to the network, and we wait for it to mine.\n\n#### Approve the Meta-Payload\n\nOnce the transaction is mined, other members of the multisig will see see the proposal, which contains the **meta-payload**. If enough of them approve it, the transaction will finally be sent! And if you're reading this on SmokeSignal.... It worked! The multisig approved the instruction to the forwarder, to send a `burnMessage` transaction to SmokeSignal.\n\nWhew!\n\n### How Foundry Governance will post similar messages in the future\n\nOnce Foundry Governance is completed, Team Toast will transfer the ownership of the Forwarder/Treasury to Governance. So our stack will be pretty similar, with #1 changed:\n\n1. A FRY holder constructs and submits a **Foundry proposal** ...\n\n2. ... for the **Foundry Treasury** to submit a transaction...\n\n3. ... to post a message to **SmokeSignal** with a given topic and some DAI burned.\n\nOnce submitted, the proposal will be voted on by FRY holders--a more decentralized analog of today's multisig members voting the proposal in.\n\nBut because it's still the same Treasury (more to the point, the same smart contract address) that forwards the **core payload** to SmokeSignal, the identity--and the phace you see to the left of this message--will remain the same.\n\nThus, in the same way that this message could not be posted without consent from the Team Toast Multisig, once Governance takes over, further messages from this identity cannot be posted without consent from FRY holders (however Governance defines that consent--check out the [Foundry White Paper](https://github.com/team-toast/foundry-design/releases/latest/download/foundry-design.pdf) for the current design).\n\n### Why is this important?\n\nThis will allow Foundry to express itself on SmokeSignal. These expressions will be uncensorable, permanent, public, and unforgeable, and will represent the collective expression of largely pseudonymous FRY holders. Foundry will act as a cohesive agent, capable of making claims and promises--and backing these up with the weight of a Treasury full of assets such as DAI, ENS domain control, bounties, and burnable payments, and general interaction with any Ethereum smart contract system.\n\nTo read more about Foundry, FRY, and Team Toast, check out [foundrydao.com/fry/](foundrydao.com/fry/).","v":2,"c":{"topic":"foundry"}}