This is the third post in a series featuring ideas for autonomous services from Autonolas community members. It's brought to you today by guest author and community member Odin.THOR. Odin.THOR has been doing some impressive thinking about compelling ideas for autonomous services, and we wanted to share them with the community. Let us know what you think, and feel free to also share your own ideas with everyone on Twitter or Discord–you might be the next author featured on the blog!

#1 : Legacy Agents

Purpose: Allow individuals to financially influence and strategically support causes they believe in, beyond their natural lifetimes.

Overview: Historically, the encapsulation of monetary assets as ‘societal debt’ has allowed significant social contributors to shape the society they lived in, oftentimes even after their death. The Nobel Prize serves as an exemplary characterization of this idea. However, in its current form, does the Nobel Prize continue to recognize talent in the same manner Alfred Nobel, the original sponsor of the award, would?

What if, instead of people, with their predilection for bias and potentially misaligned incentives, the task of selecting award recipients could be assigned to an intelligent agent network, modeled after Nobel’s recorded behavior?

The autonomous agents which constitute this network could also be explicitly directed to fulfill Nobel’s long-term objective, without revealing it to any live individuals. Such a service, while somewhat fantastical, is technically achievable today using Autonolas’s technology.

Path to Implementation: An agent network will be endowed with a machine learning model initially informed by a) explicit goals from the user (eg: reduce cancer mortality) and b) data regarding the user’s moral tendencies and past decisions. This model will be further refined by incorporating occasional feedback from the user, over the course of their lifetime.

Feedback will entail financial reactions from the user in response to simulated situations (assuming perpetually zero cost of living). The simulated situations will oscillate between a) mimicking historically accurate scenarios (eg: war/financial collapse) and b) enacting hypothetical, but possible, situations (eg: energy crisis/climate shift).

Upon the user’s death, funds will be willed to the Autonolas service by either a legal executor or a more transparent alternative like Sequel Finance. The service will then actively identify and contribute funds to actors it predicts will support the user’s long-term goal.

Any unallocated funds will be deposited into a productive low-risk yield strategy (eg: Stablecoin LP-Pool) to protect against erosion/inflation. Agent operators, in exchange for maintaining the service, will be entitled to any returns accrued beyond the ‘Principal Protection Rate’ (eg: Inflation + dynamic % of Inflation).

Periodically, (every 2-3 yrs) agent operators may collectively vote to move the principal to any insured yield-generating opportunity supported by whitelisted insurance providers (eg: Risk Harbor). The agent network will be hard-coded to check if the deposited funds are eligible for an insurance payout every 3-6 months (indicating a hack/risk management failure). If an insurance payout successfully occurs on-chain, the recovered principal will then be assigned to different operators to lower the chance of future loss to poor risk management.

Finally, the user will also be able to assign an on-chain wallet a limited number of veto votes as NFTs. (The keys to this wallet can be given to a close family member/inherited by children.) Before making a major on-chain commitment, the agent network will broadcast upcoming principal allocation decisions (in cipher) via an empty transaction to a burn address. The veto wallet can prevent undesirable decisions by responding with a transaction containing a veto NFT and the corresponding decision number(s) in the memo field. Successful veto votes will be used to further improve the decision-making model.

#2 : Employment Bonds

Purpose: Allow DAOs to offer employees greater income security while simultaneously strengthening inter-DAO relationships and establishing an additional stream of passive income.

Overview: A significant barrier to entry for many aspiring Web3 developers is their inability to safely expect a reliable stream of income from the DAOs they hope to work with, especially when those DAOs are new and unproven.

Unfortunately, the finances of several new projects are managed almost entirely by team-operated multi-sig wallets, making them vulnerable to both ‘rug- pulls’ by pseudonymous teams and sophisticated social engineering attacks.

However, what if it were possible to maintain the maneuvering advantages of team-centralization (i.e. not requiring a community vote for every decision) while still keeping funds earmarked for employees financially productive?

There are two main gaps DAOs must bridge to achieve this goal:

i) Retaining the ability to terminate employment in valid cases (without employee fear of unfairly losing employment/future pay).

• Simplest solution [Subjective-Decision Issue]: DAO-DAO Collaboration.

ii) Enforceable employment terms (consistent workforce) while allowing employees to remain pseudonymous (not share their public identity with DAO).

• Simplest solution [Privacy Issue]: zk-computation + legal enforcement

Path to Implementation: When they begin work, each pseudonymous employee will sign a notarized long-term employment contract and submit it to an Autonolas service. The service will parse the submitted contract and ensure it meets the employment conditions stipulated by the employing DAO. (As a fallback - agent network can autonomously contact notary via email and seek clarification regarding document contents/authenticity.)

A key component of all contracts will be that the signing employee can be transferred to a separate employer for the remainder of their term (assuming same benefit/wage level). The employer (DAO) will never be given access to the contract unless they seek to take legal action against their employee (keeping the identity of the employee private).

If legal action must be taken, the corresponding complaint/lawsuit will need be filed through the Autonolas service (which can be incorporated as a legal entity). This will help ensure the complaint cannot simply be withdrawn by the DAO upon learning the employee’s identity.

After an employee contract is signed, the DAO will delegate the funds needed to meet its wage obligation over the employment term to an insured yield- generating opportunity. These funds will be controlled through the Autonolas service. Every month, the pre-agreed wage amount will be sent to the employee by the service on-chain. The DAO will have the option to claim the yield generated upon the deposited principal at any point (to allow for optimal compounding).

With this housekeeping out of the way, let us revisit issue (i) outlined in the overview. At the beginning of each financial year, the employer DAO will identify another DAO with a similar number of employees and wage obligations to form an ‘Accountability Partnership’ with. In the event either DAO becomes insolvent or is disbanded, the operational DAO will claim the employees from the insolvent DAO (wages will continue to be paid from the principal deposited with the Autonolas service).

If either DAO wishes to fire an employee, the other DAO will evaluate if the termination is acceptable (external validation). If the termination is deemed appropriate, severance will be paid out from the Autonolas service, and the remaining wage principal will be returned to the initial employer. If the termination is deemed inappropriate, the DAOs will ‘trade’ similar-level employees between each other such that the employee-under-review is assigned to the other/new DAO.

Let us consider a few examples to make this more digestible:

Conditions: i) DAO α and DAO β have a similar number of employees at the same wage level ii) DAO α and DAO β enter into an Accountability Partnership iii) Employee wages for both DAOs have been pre-deposited with the Autonolas service iv) To dismiss an employee (terminate wage payment) DAO α requires approval from DAO β and vice-versa v) DAO α can claim any of DAO β’s initial employees at any time and vice-versa vi) DAO α cannot reclaim any of their initial employees that have been claimed by DAO β and vice-versa (max. one movement per employee) vii) All DAO-employee actions will be taken via on-chain instructions to the Autonolas service from the DAO’s multi-sig viii) Legal action can be taken against an employee by their current employer through the Autonolas service

Examples:

Example A: DAO α is disbanded due to project failure.

• Response: DAO β claims DAO α’s employees with no resistance from DAO α (which no longer exists).

Example B: DAO α places a hostile claim on one of DAO β’s employees.

• Response: DAO β claims an employee of similar standing from DAO α.

Example C: DAO α wishes to dismiss an employee

• Response: DAO β will manually review employee performance to assess if termination is appropriate. If it is, DAO β will approve the termination request with the Autonolas service and unpaid wages (-severance) will be returned to DAO α. If DAO β determines termination is not appropriate, DAO β will claim the employee in question from DAO α, and DAO α will claim an employee of similar standing/role from DAO β.

These examples may suggest that DAOs engaged in such partnerships will always ‘be at each other’s throats’. However, in practice, I expect partnered DAOs will only interact with each other regarding employees in rare and extreme circumstances.

In fact, since each DAO has the capacity to effectively restructure the other’s workforce, partnered organizations will need to maintain a close level of trust and communication which could very possibly pave the way for additional shared ventures.

Another weakness of this model is that, like much of over-collateralized crypto, it is not very capital efficient. However, in exchange for some capital inefficiency, DAOs will be able to maintain a more reliable workforce and employees will be able to confidently dedicate their time to a single project without the need to ‘doxx’ themselves.

#3 : Interactable Certificates of Net-Worth

Purpose: Identify users with specific portfolio types (omni-chain & off-chain) in a privacy-preserving manner with adjustments for historical distribution.

Overview: Token airdrops and feedback from alpha-stage users are often central in new projects’ strategies to gain traction with their target audience. Currently, users selected to receive airdrops or alpha-stage access are chosen using contextual information which suggest their interest in either the project itself or a similar/complementary industry.

However, many of these methods can fall prey to mercenary ‘airdrop hunting’ or, more simply, users with transitory/short-term interest in the project. A better indication of a user’s convictions would be proof of ‘where they are putting their money’.

To quantify this, what if it were possible to probe a user’s portfolio with granular selectivity by running a privacy preserving query against the sum of their assets and investments?

Path to Implementation: In order to generate a Certificate of Net-Worth, users will be asked to provide an Autonolas service read-only access to their off-chain CEX/banking/investment accounts via Web2 APIs. Users will also be asked to provide their wallet addresses across chains and confirm they have provided access to all appropriate accounts/holdings via a legally binding agreement.

The generated ‘certificate’ will then be stored within the Autonolas service and updated whenever a query is requested against it by a participating protocol (eg: Curve, Balancer). Each of the user’s wallets will be assigned a wallet-unique code written to an SBT, allowing the service to associate the wallet with the main certificate when a query is requested.

On the protocol side, once a user connects a wallet with an SBT from the Autonolas service, and provides consent for a query to be run, zero-knowledge proofs will be used to output a binary yes/no result.

An example would be: Step 1: An NFT trading platform (eg: OpenSea, SudoSwap) launches a new token and is airdropping a percentage to eligible users on a first-come/first- serve basis.

Step 2: A user with interest in NFT artwork connects their wallet with an Autonolas service SBT to the NFT trading platform.

Step 3: The NFT platform, having verified that the user owns the wallet, will transmit the wallet’s identity to the Autonolas service with a query request.

Step 4: The query can range from: “Is >15% of the user’s portfolio in the NFT artwork industry?” To: “Did the user receive and still hold tokens from a competitor’s airdrop?” (Identity of competitor’s token + Date window during which competitor’s airdrop could be claimed)

Step 5: A yes/no answer is generated using zk-proofs and provided to the NFT trading protocol.

Note: The protocol will only be allowed to run a query once per month to ensure:

a) Different query parameters cannot be run to extract additional details regarding the user’s portfolio.

b) The user cannot temporarily restructure their portfolio to ‘game the system’ and become eligible for a lucrative airdrop.

Thank you for taking the time to read through these ideas! If you find any of them to be of interest to you or your team, visit our Discord to start a conversation with the community!

Written by Odin.THOR Twitter: @ODIN_Thorchain