DeepAI
Log In Sign Up

Decentralized Autonomous Organizations for Tax Credit's Tracking

05/20/2022
by   Giovanni De Gasperis, et al.
0

Tax credit stimulus and fiscal bonuses had a very important impact on Italian economy in the last decade. Along with a huge expansion in constructions a relevant increase in scams and frauds has come too. The aim of this article is to design a possible system to track and control the whole tax credit process from its generation to its redeem through a Decentralized Autonomous Organization architecture enriched with a Multi Agent Systems to implement controllers.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

02/22/2022

Event-Triggered Tracking Control of Networked Multi-Agent Systems

This paper studies the tracking control problem of networked multi-agent...
10/10/2022

Learning Credit Assignment for Cooperative Reinforcement Learning

Cooperative multi-agent policy gradient (MAPG) algorithms have recently ...
11/12/2019

Arbitrage opportunities in publication and ghost authors

In some research evaluation systems, credit awarded to an article depend...
03/23/2020

Graph Neural Networks for Decentralized Controllers

Dynamical systems comprised of autonomous agents arise in many relevant ...
07/07/2021

A Decision Model for Decentralized Autonomous Organization Platform Selection: Three Industry Case Studies

Decentralized autonomous organizations as a new form of online governanc...
09/04/2018

Constructing Trustworthy and Safe Communities on a Blockchain-Enabled Social Credits System

The emergence of big data driven technologies has greatly changed global...
10/19/2019

CreditPrint: Credit Investigation via Geographic Footprints by Deep Learning

Credit investigation is critical for financial services. Whereas, tradit...

1 Introduction: Tax credit stimulus in Italian law

A brief history of tax credit measures in Italy. Italian energy policies and laws have a deep root into European Union guidelines, these mainly aim to improve the performance and to reduce the wastefulness of households energy production systems. During the last years the debate around energy efficiency rose in importance and is now central to determine the Next Generation EU funding policies, As a EU Member, Italy has taken steps to encourage energy efficiency increase of residential buildings. A program of tax deductions and fiscal bonuses, originally introduced in 1997 (art.1 Law 449/1997) 111https://www.gazzettaufficiale.it/eli/id/1998/01/28/098A0239/sg were relaunched since 2011 (art.4 DL 201/2011)222https://www.gazzettaufficiale.it/eli/gu/2011/12/06/284/so/251/sg/pdf and renewed over the years till 2019. Finally during 2020 the actual system of 110 percent Superbonus tax credit has been introduced (Art. 119 DL Rilancio 34/2020)333https://www.gazzettaufficiale.it/eli/id/2020/05/19/20G00052/sg. For the first time the lawmaker set up a system where energy efficiency and structural works are at no cost for residential properties.

The actual legislation and the invoice discount. Superbonus 110, unlike other tax allowances for energy efficiency measures and reduction of seismic risks of buildings, provides for a higher-than-investment rate of deduction as well as a different way of allowances claim. In fact for each 100 euros spent on renovation works, the buyer will mature a 110 euros tax deduction to be used over the next 5 years and divided into 5 equal annual instalments. Since the annual deduction is discounted from the taxpayer’s gross tax (IRPEF), it is therefore recoverable within the limit of such amount and cannot be carried forward or claimed back. Any deduction in excess of the gross tax would be lost. The legislator has thus provided two alternative solutions to the direct deduction: a discount on the invoice received for the works or assignment/selling of the matured credit to a third party. The option considered and modeled in this paper is the Invoice Discount as it is the most diffused solution and, differently from direct selling or direct deduction, requires credits to be tracked and managed as the benefits may be transferred through many subjects during the generation and redeem process. It consists of a contribution in the form of a discount on the invoice, up to an amount equal to the total including VAT, to be requested to the construction companies. It in turn may monetize it by either using it in compensation for future taxes to pay or by selling such right to third parties (in most cases Financial Institutions). The critical features of invoice discount mechanism are the following: Customers have no disbursement for the restoration works; fiscal and technical visas are required to certify credits matured from the discounted invoices; Suppliers of goods and services are financially exposed, as do not receive cash payment for their invoices but accrues a tax credit equal to the deduction matured by the Costumer/Taxpayer and Suppliers may in turn assign/sell the credit to other parties. Another assumption we make in this paper is that the Costumers are using a General Contractor to manage the whole process of renovation on the construction yard and connected paperworks. This is both in order to simplify the level of the model (which in turn can be easily extended to a multi supplier situation) and to describe the most diffused scenario.

Figure 1: Invoice Discount Tax Credit generation.

The General Contractor will be the only subject dealing with the Costumer, he will take care of coordinating and paying all the sub-contractors involved in the renovation works as well as all professionals and technicians required both for technical and financial projects and certifications. As a result the discounted invoices will be raised only by the General Contractor which in turn will pay cash all the Suppliers and Professionals aforesaid, thus will be the only subject entitled to get the tax credit matured by the Costumer.

Tax fraud mechanism and credit tracking. In such an environment is of paramount importance being able to track the history of credits as well as the identity of all players involved in the process. Identity scams and credit assignment to fraudster recipients are in fact the main risks involved in Superbonus 110 process. Another risk, not connected necessary to willing to fraud, is represented by incorrect credit assignment where for example a client asks for a bigger amount than owed or more properties than allowed. In all of these situation back tracking of each euro of tax credit assigned is of key importance.

A brief introduction to Distributed Autonomous Organizations. The idea of Distributed Autonomous Organizations (DAOs) has been outlined for the first time during the late 90s and was connected to the application of Multi-agent Systems to intelligent home sensors [1]. With the introduction of the Digital Autonomous Corporations concept (DACs) after 2008, a first transposition of a real company on the blockchain was defined; taking advantage from the introduction of Ethereum instruments like tokenization of shares, fully automated and incorruptible smart contracts along with transparent transactions register were finally applicable to the real governance process of a company [2]. The actual DAOs paradigm is an evolution of the DACs one, on the technical perspective it refers to a system able to model an organization through the deployment of a set of interacting smart contracts upon a blockchain network. It also inherit the properties of the underlying layers such as lack of centralized control, security through cryptographic keys and self-execution of smart contracts. All these properties make DAOs a reliable paradigm to operate a virtual organization modeling all functionalities and procedures of a real one.

2 Main purpose: DAOs for Tax Credit’s tracking

Roles, Actors and entities. The aim of this paper is to investigate the application of DAO paradigm to manage the procedures of Superbonus 110 evaluating a possible integration with a MAS based intelligent control system. The first step is to identify the environment and the entities involved in the process, we identified to start two main areas: the investors group which includes all actors getting financial burdens and benefits in the process, and the operators group that in turns aggregate all actors with on-the-job interests in the Superbonus. Some actors may take both groups properties as per Table 1.

Group Actors Role and Actions
Investors Investor Invest money to buy credits and benefits from its selling
Investors-Operators Financial Institution Banks that buy/sell credits and lend money to Operators
Investors-Operators Customer House owner Sells/Transfers tax creditsfrom works
Operators General Contractor Manages works, gets credits from Customers, sells to Financial Institutions
Operators Sub-contractor Hired and paid by General Contractor
Operators Supplier Hired and paid by General Contractor
Operators Design Architect Hired and paid by General Contractor
Operators Tax Auditor Hired and paid by General Contractor
Table 1: Users and Roles

Double DAOs architecture. The software and logic architecture proposed to implement the interaction between such actors is based on the separation of investors’ world by the operators’ one. This is due to consent Financial Institutions to raise fund from clients and investors and tokenize such assets, the process is made assuming a simplified model where banks receive transfers of fiat on their accounts and mint the correspondent value of tokens on the first DAO, the Investors one. Another key feature is to guarantee that money anticipation performed by financial institutions and the correspondent underlying credit generation is backed by a fiat asset and is thus repayable when the credits’ chain is closed. In brief the first DAO system, named Superbonus Investors, is meant to represent a simplified investing fund where participants get tokens proportionally to their investment, keep them blocked until the end of the fund duration and get a reward proportional to their initial quota at the end. Here we have Non Fungible Tokens (NFT) that are minted upon fiat deposit or credit selling by the Financial Institution and freezed or unfreezed when a guarantee from Operators DAO is requested or released. The architecture can be seen as a Distributed Trust and Reputation Management Systems (DTRMS) environment implemented through two DAOs.

Figure 2: DAOs Interaction Diagram.

The second DAO is basically a marketplace where the Financial Institution distribute fungible tokens to General Contractors, these are minted and burned in order to satisfy credit request from Operators and spending for buying good and services. Each minting on Operators DAO correspond to a token freezing of the same amount on first DAO in order to guarantee the coverage. The tokens are redeemable by the Financial Institution that is also warrantor of the whole system. Once second DAO tokens are redeemed, first DAO NFTs are unfreezed. Each fungible token minted here is coupled via a unique code to the tax credit generated by that spending of money.

Aragon as developing platform. The framework chosen to develop our demonstrator is Aragon 444https://aragon.org/. This is a second level platform based on the Ethereum network 555https://ethereum.org/ that is natively designed to model government systems of public and private entities, it is easy to use and allows to deploy test nets for application at very cheap costs using Ethereum’s test nets such as Rinkeby 666https://www.rinkeby.io/. Another feature of the Aragon framework is that completely manages the layers necessary for communication between the dApp and the Ethereum Virtual Machine (EVM); in this way it is possible to concentrate on the development of business logic and the interaction with external smart contracts via the Agent module of the framework. The Aragon stack is mainly composed of: an Operative system environment where applications are abstracted from the underlying layer, a Packet Manager to distribute different versions of the software, APIs to manage requests on transactions, status and software without depending on a centralised service and a toolkit for the development of the dApps user interface.

Internal DAOs Smart contracts. The model described in the previous section is implemented through several smart contracts, deployed for this demonstration on Rinkeby test net and integrated with the Aragon management platform. Contracts runs on the Ethereum Virtual Machine and are written with Solidity 777https://soliditylang.org/ an object-oriented language specifically meant for contract contracts implementation. The choice of such stiff language is because we want the execution to be strictly what is supposed to be without possibility of . A solidity example of Operators token minting function is illustrated below:

1function MintOperator(address _to, uint256 _amount) external auth(MINT_OPERATOR_ROLE) {
2    //Unfreezed Investor plafond must have at least the same amount of Operator Tokens that we want to mint
3    require(getUnfreezedInvestorBalance() >= _amount);
4
5    //Burn Unfreezed Investor Token first
6    BurnUnfreezedInvestorToken(_amount);
7
8    //Mint same amount of Freezed Investor Token with the Operator Token’s LinkID
9    MintFreezedInvestorToken(_amount);
10
11    //Then Mint real Fungible Operator Tokens and assign them to the target owner
12    MintOperatorToken(_to, _amount);
13}

A representation of Smart contract’s states along with global and local constrain, data structures and actors involved is instead reported in Figure 3

Figure 3: Smart Contract View.

Integration of Multi Agent Systems. We have integrated a simple module composed of 4 Agents in order to control main aspects of the Investors an Operators DAOs and suggest the future behaviour of the Financial Institutes in terms of token needs of the system . Com-agents manage the data exchange with the DAOs, the Prediction-agent forecasts token needs on Operators DAO while Control-agent checks the correct behaviour of operators in claiming credits and points put potential fraud or incorrect schemes. We used the MESSAGE/UML paradigm to model the agent interaction and behaviour[3] in Figure 4

Figure 4: MAS architecture.

3 A sample application (or demonstrator)

The demonstrator we have implemented is meant to illustrate the benefits of introducing the DAOs and MAS to Superbonus 110 environment. The actual procedure has two weak point: the first is the difficulty to track the credits and the second the disbursement of anticipated cash both from Financial Institutions and General Contractors. In this way we’ll focus on two main features of the software in order to simulate the substitutions of cash with Operators tokens and the tracking of the matured credits through a spreading tree. It will be possible to track the tokens coupled to tax credit and represent their path as a tree where the root is the first minting action. Furthermore the MAS modules will point out potential fraud situations and forecast the token request path in a certain time lapse.

Figure 5: Demonstrator User Interface.

4 Conclusions

The goal of our demonstrator is to track the life cycle of tax credits generated by Superbonus 110 incentives scheme. The model used could be easily exported to other areas both in the institutional and private sectors. In particular public administrations may benefit of a reliable governance and voting system to provide services that requires tracking of items and documents (eg. Board resolutions, Certifications, etc)[4]. More in general every process where a tracking of some asset or document is required could benefit from the architecture of Blockchain in the environment of Distributed Trust and Reputation Management Systems (DTRMS)[5]. Another possible future development may consider the integration of smart contracts and agents with IoT solutions such as sensors to monitor physical quantities.

4.0.1 Sample Heading (Third Level)

Only two levels of headings should be numbered. Lower level headings remain unnumbered; they are formatted as run-in headings.

Sample Heading (Fourth Level)

The contribution should contain no more than four levels of headings. Table 2 gives a summary of all heading levels. Table 2 gives a summary of all heading levels.

Heading level Example Font size and style
Title (centered) Lecture Notes 14 point, bold
1st-level heading 1 Introduction 12 point, bold
2nd-level heading 2.1 Printing Area 10 point, bold
3rd-level heading Run-in Heading in Bold. Text follows 10 point, bold
4th-level heading Lowest Level Heading. Text follows 10 point, italic
Table 2: Table captions should be placed above the tables.

Displayed equations are centered and set on a separate line.

(1)

Please try to avoid rasterized images for line-art diagrams and schemas. Whenever possible, use vector graphics instead (see Fig. 

6).

Figure 6: A figure caption is always placed below the illustration. Please note that short captions are centered, while long ones are justified by the macro package automatically.
Theorem 4.1

This is a sample theorem. The run-in heading is set in bold, while the following text appears in italics. Definitions, lemmas, propositions, and corollaries are styled the same way.

Proof

Proofs, examples, and remarks have the initial word in italics, while the following text appears in normal font.

For citations of references, we prefer the use of square brackets and consecutive numbers. Citations using labels or the author/year convention are also acceptable. The following bibliography provides a sample reference list with entries for journal articles [ref_article1], an LNCS chapter [ref_lncs1], a book [ref_book1], proceedings without editors [ref_proc1], and a homepage [ref_url1]. Multiple citations are grouped [ref_article1, ref_lncs1, ref_book1], [ref_article1, ref_book1, ref_proc1, ref_url1].

References