By virtue of being public and deterministic, smart contracts enable novel approaches to business engagements. Where and when this novelty has real utility, however, is a matter still early in the unfolding.
Whether one chooses to adopt smart contracts as instruments for their business or organization depends on one's aims and circumstances. This new technology enables transparency, trustlessness, and composability in new and exciting ways, but these values may not be important in every situation, and the complexity of this technology can constitute serious cognitive overhead.
That said, if this technology does appeal to a given business or organization, then the question shifts from whether to use it, to how to use it.
In this newsletter, business and nonprofit applications of this technology will be explored, with an emphasis on consulting. This entry in particular will focus on whether and how consultants should use this technology to engage with clients.
None of the following constitutes legal or financial advice, and is purely for informational purposes.
Engagement-Bound Wallets
If a consultant is planning to engage with clients in some on-chain capacity, whether that is as simple as receiving cryptoassets as payment or as complex as managing a number of smart contracts, they should have clear practices in place regarding security and accounting. Across the industry, such best practices are still being determined through experimental modes of engagement.
One question which serves as a point of departure, in terms of developing such a methodology, is the following: to what extent should consultants use unique wallets and contracts for each engagement? That is, should a consultant create new wallets and deploy new smart contract instances for every engagement they open?
Some examples are relatively clear, such as Smart Invoice contracts, which are intended to be limited to a particular engagement. Other examples, such as whether a consultant should use one wallet to receive payments across a number of engagements or whether they should use a unique wallet for every engagement, is arguably less clear.
One benefit for using a unique wallet for every engagement is that it arguably simplifies accounting to the extreme. That is, if a consultant dedicates a wallet to a given engagement with a client, both the consultant and the client can be confident that the transaction history of that wallet is pertinent to their engagement, in terms of accounting. A downside, however, is that it involves greater cognitive overhead for the consultant, seeing as they'd have to keep track of an arbitrary number of wallets, even if these wallets are retired upon closing an engagement.
Adopting such a technique depends on the preferences of the consultant, namely whether they'd prefer the siloed organization of their engagements, or the operational simplicity of using a single wallet across multiple engagements. This decision may also depend on how compliance and reporting requirements develop, such as whether the IRS eventually requires independent contractors to report on-chain payments in certain ways. If using multiple wallets ends up entailing multiple unnecessary taxable events, then that is another factor to consider.
Engagement-Bound Smart Contracts
Aside from wallets, smart contracts constitute the other main category of on-chain instruments. As far as business and organizational applications go, examples of smart contracts include multi-signature or "multisig" wallets, smart invoices, and smart escrow accounts. Each of these instruments involve users creating unique instances of these tools, to be used in particular engagements or enterprises. Moreover, they all involve the facilitation of funds or assets.
Some of these tools, such as smart invoices and smart escrow accounts, are designed to be used in a particular engagement and retired thereafter. Others, such as multisigs, can be used in such temporary capacities, or in more perennial capacities, such as company treasuries.
That said, many of the same considerations apply here as they do for wallets. If every on-chain instrument involved in a given engagement, wallets and smart contracts alike, is dedicated to that particular engagement, not only is accounting simplified, but external risk is arguably minimized. That is, a wallet which has a history of smart contract interactions, some of which may include the allowance of ongoing permissions, has an equal or greater attack surface than a wallet which is freshly created for a particular engagement.
What To Do?
Should consultants approach on-chain engagements in maximally siloed manners, or does such an approach involve unnecessary complexity? Ultimately such a decision depends on several factors, such as the personal preferences of the consultant and/or client in question, and the reporting requirements they are subject to.
While this newsletter is exploratory in nature, it is nonetheless worthwhile to ask how useful a theoretical practice would be, and how justified its complexity. Do the capabilities enabled by switching to a new methodology warrant the cognitive overhead involved? Many of the new practices this technology will enable, including those covered above, deserve to be explored, but how meaningfully such pure innovation may be applied is a matter we, as an industry, are to determine.
