#  : Code Generation for Few-Shot Event Structure Prediction

Xingyao Wang  Sha Li  Heng Ji
University of Illinois Urbana-Champaign, IL, USA
{xingyao6, shal2<EMAIL_ADDRESS>
###### Abstract

Large Language Model (LLM) trained on a mixture of text and code has
demonstrated impressive capability in translating natural language (NL) into
structured code. We observe that semantic structures can be conveniently
translated into code and propose to leverage such text-to-structure
translation capability to tackle structured prediction tasks. As a case study,
we formulate Event Argument Extraction (EAE) as converting text into event-
argument structures that can be represented as a class object using code. This
alignment between structures and code enables us to take advantage of
Programming Language (PL) features such as inheritance111Inheritance is a way
to create a hierarchy of classes in PL. A child class can base upon another
class, retaining similar implementation. and type annotation222Developers use
type annotations to indicate the data types of variables and input/outputs of
functions. to introduce external knowledge or add constraints. We show that,
with sufficient in-context examples, formulating EAE as a code generation
problem is advantageous over using variants of text-based prompts. Despite
only using 20 training event instances for each event type, is comparable to
supervised models trained on 4,202 instances and outperforms current state-of-
the-art (SOTA) trained on 20-shot data by 29.5% absolute F1. By leveraging the
inheritance feature of PL, can use 10-shot training data from a sibling event
type to predict arguments for zero-resource event types and outperforms the
zero-shot baseline by 12% absolute F1. 333All code and resources are publicly
available at https://github.com/xingyaoww/code4struct.

Figure 1: Event Argument Extraction using code generation. We convert the
existing event type ontology to Python class definitions. Conditioned on these
definitions, we put the input sentence for event argument extraction into a
docstring as the prompt for code generation. The generated code (colored in
green) can be mapped to an instance graph of Transport event.

##  1 Introduction

Table 1: Mapping between Event Argument Extraction requirements and features
of Python programming language.

Large Language Model (LLM) trained on massive corpora of code mixed with
natural language (NL) comments and docstrings444Text used to document a
specific segment of code. (e.g., Chen et al. 2021, Nijkamp et al. 2022) has
demonstrated the ability to translate natural language instructions into
structured code. We ask if this conversion between language and code can serve
as a bridge to build a connection between language and semantic structure,
which is the goal of many structured prediction tasks (e.g., semantic parsing,
information extraction) in Natural Language Processing (NLP). In particular,
the target structure (e.g., event-argument graph in Figure 1) can be mapped to
code more straightforwardly compared to natural language, which often requires
careful prompt engineering (Hsu et al. 2022, Li et al. 2021, Table 2). In
addition, code written in programming languages has an inherent advantage in
representing complex and interdependent structures Miller (1981); Sebrechts
and Gross (1985) with features such as inheritance and type annotation.

As a case study, we showcase our proposed on the Event Argument Extraction
(EAE) task, which aims to extract event structures from unstructured text. EAE
is the ideal testbed for our method due to the close alignment between EAE and
PL as shown in Table 1. In (Figure 1), we first translate the entity and event
type ontology into Python class definitions. Conditioned on the relevant class
definitions and the input sentence, we prompt an LLM to generate an
instantiation of the event class, from which we can extract the predicted
arguments.

By leveraging the alignment between PL and NLP problems, enjoys various
advantages as shown in Table 1. Using PL features like type annotation and
argument default value, we can naturally enforce argument constraints for
output structures. This allows to handle multiple or zero argument fillers for
the same argument role by annotating the expected type (i.e., expect a list of
entities) and setting the default value for each argument (i.e., an empty list
without any entity by default). Furthermore, we can naturally utilize the
event hierarchy by leveraging inheritance. Inheritance allows a child event
class (e.g., Transport) to reuse most components of its parent class (e.g.,
Movement) while preserving its unique properties. We demonstrate that
hierarchical event types allow zero-resource event types to use annotated
training examples from their high-resource sibling types (§4.6).

We outline our contributions as follows:

  * •

We propose to tackle structured prediction problems in NLP using code
generation. As a case study, we use for Event Argument Extraction (EAE).

  * •

We perform extensive experiments contrasting the performance of code-based
prompt and two variants of text prompt on different LLMs and show that code
prompt is generally advantageous over text prompt when sufficient in-context
examples are provided (§4.2).

  * •

We demonstrate that 20-shot rivals fully-supervised methods trained on 4,202
instances. outperforms a SOTA approach by 29.5% absolute F1 gain when 20-shot
data are given to both. 0-shot can even outperform the SOTA on both 20 and 50
shots (§4.5).

  * •

We show that integrating the event ontology hierarchy by class inheritance can
improve prediction. Compared to the zero-shot baseline, we see 12% F1 gains
for zero-resource event types when using 10-shot examples from their sibling
event types (§4.6).

Figure 2: Prompt components. (1) Ontology code representation contains
definitions of entity and event classes, colored in yellow and blue (§2.1).
(2) $k$-shot examples for in-context learning, colored in orange (§2.3). (3)
The task prompt, appended at the end with partial class instantiation for LLM
completion, colored in green (§2.2).

##  2 Code Generation Prompt Construction

In Event Argument Extraction (EAE) task, a model is provided with an event
ontology and the target text to extract from. Similarly, we prompt an LLM with
the ontology that consists of definitions of event types and argument roles,
and input sentences to generate code that instantiates the given event type.
We breakdown the input prompt into three components: (1) ontology code
representation which consists of Python class definitions for entity types and
an event type (§2.1); (2) optional k-shot in-context learning examples for the
event type defined in (1) (§2.3); (3) task prompt for completion (§2.2). We
show a breakdown of the full prompt in Figure 2.

###  2.1 Ontology Code Representation

To represent the event ontology as code, we concatenate the base class
definition, entity class definitions, and event class definitions.

##### Base Class Definition

We define base type Entity and Event to be inherited by other classes.

##### Entity Class Definition

We use entity type definitions from the Automatic Content Extraction (ACE)
program555https://www.ldc.upenn.edu/collaborations/past-projects/ace. We
construct Python classes that inherit from Entity and use the entity type as
the class name (e.g., class GPE(Entity)). We add a natural language
description as a docstring of the defined class for each entity type.

####  2.1.1 Event Class Definition

We define the event class using the name of the event type (e.g., class
Transport). As ACE defines its event types in a hierarchical ontology,
mimicking class definitions in Object-Oriented PL, we inherit the event class
definition from its parent (e.g., class Transport(Movement)) or root event
type if the event class does not has a parent (e.g., class Movement(Event)).
An example of hierarchical event definition can be found in Figure A.9.

We define the argument roles (e.g., destination of Transport) as input arguments of the constructor __init__666A constructor is a special function that initializes an instance of a class.. We specify the type of each argument role using Python type annotation, a commonly used PL feature: For example, agent: List[GPE | ORG | PER] means that the agent argument accepts a list of entities which could be either of type GPE (Geo-Political Entity), ORG (Organization), or PER (Person). We assign each input argument (e.g., agent) to a class member variable of the same name.

We include event description templates into the docstring of the class
definition. The event description templates are modified from Li et al. (2021)
by replacing each role with their corresponding member variable (e.g.,
self.agent).

Prior Work |  Language Template
---|---
DEGREE Hsu et al. (2022) |  somebody was moved to somewhere from some place by some way. somebody or some organization was responsible for the movement. something was sent to somewhere from some place. somebody or some organization was responsible for the transport.
BART-Gen Li et al. (2021) |  <arg1> transported <arg2> in <arg3> vehicle from <arg4> place to <arg5> place
Text2Event Lu et al. (2021) |  ( (Transport returned (Agent <arg>) (Artifact <arg>) (Destination <arg>) (Origin <arg>) (Vehicle <arg>) )

Table 2:  Example of language templates for Event Argument Extraction used by
Hsu et al. (2022); Li et al. (2021); Lu et al. (2021).

###  2.2 Task Prompt

The task prompt consists of a docstring describing the task and incomplete
event instantiation code for completion. An example of a task prompt can be
found in Figure 2. The text-based docstring contains a task instruction and an
input sentence. We mark the ground truth trigger words for the input text by
surrounding them with **. We choose to use ** as it is used to set text to
bold in Markdown (a markup language for creating formatted text), which is
commonly found in code bases and web data on which our LLM is trained. The
incomplete code prompt assigns a partial instantiation of an event class to a
variable to trigger the model for completion, for example, transport_event =
Transport(.

We observed that LLM tends to generate additional sentences paired with
extracted arguments if no stopping constraint is applied. To focus on the
given EAE task, we stop the code generation whenever any of the following
patterns is generated by the model: """, class, print, or #.

###  2.3 In-context Learning

Optionally, we can include in-context learning examples, which are task
prompts (§2.2) paired with completed event instantiations using ground-truth
arguments (see Figure 2 for a specific example). For $k$-shot learning, we
concatenate $k$ such examples together. Given a task prompt, we
deterministically gather $k$ learning examples by collecting training
instances with the same event type, following the order of occurrences in the
training set.

##  3 Why Represent Event Structure in PL?

A wide range of NLP tasks have benefited from LLM Brown et al. (2020);
Hoffmann et al. (2022); Chowdhery et al. (2022) trained on web-scale language
corpora. To effectively use LLM trained on language for EAE, one of the
biggest challenges is to specify the desired output, namely event structures
in our case, using natural language.

There is a tradeoff between the effort put into defining the output or
designing the prompt (e.g., Text2Event in Table 2) and the benefit from
pretraining in natural language (e.g., DEGREE and BART-Gen in Table 2).
Text2Event Lu et al. (2021) resides at one end of the spectrum with a concise
but unnatural output format. As a result, this formulation under-utilizes the
pretraining power of the model and does not work in low-resource settings as
shown in Table 4. Towards the other end, Hsu et al. (2022); Li et al. (2021)
design manual templates for the model to fill in. We also design two variants
of language prompt as shown in Figure A.5 and A.6 miciking our code prompt and
BART-Gen style prompt for comparison. Note that these natural language prompts
are much more verbose and, as shown in §4.2, usually result in sub-optimal
performance with sufficient in-context examples.

Essentially, this tradeoff is a result of the mismatch between the pretraining
corpora and task output formats. Instead of using LLM trained on only
unstructured text, we turn to LLM trained with a mixture of text and code,
where the text is often aligned in semantics with the accompanying code. Such
Code-LLMs have the ability to convert text into corresponding code as
demonstrated by Chen et al. (2021); Nijkamp et al. (2022). Then we can map the
desired output event structure into code in a straightforward manner and
leverage the full pretraining power of these models. PLs like Python offer
features (e.g., class, docstrings, type annotations, inheritance) that have a
significant presence in the pre-training corpus of Code-LLM due to frequent
usage. leverages these features to succinctly describe event structures, which
makes it better aligned with Code-LLM. By leveraging LLM’s learned knowledge
from diverse pre-training domains, can work well in open-domain, achieving
non-trivial zero-shot performance given unseen event types (§4.5). is also
data-efficient as exemplified by reaching comparable performance to fully-
supervised methods with much fewer annotated examples (20 per event type)
(§4.5).

##  4 Experiments

###  4.1 Experiment Setup

##### LLM

We use Codex code-davinci-002 Chen et al. (2021), a GPT-3 Brown et al. (2020)
model finetuned on code, which supports up to 8k input tokens. We compare its
performance with InstructGPT Ouyang et al. (2022) text-davinci-002 and its
improved version text-davinci-003, both support up to 4k input tokens. We
access these LLMs through OpenAI API777https://openai.com/api/.

##### Hyperparameters

We prompt LLM to generate code that instantiates an event using sampling
temperature $t=0$ (i.e., greedy decoding). We set the max number of new tokens
for each generation to 128, which fits all code outputs for the test set.

##### Evaluation Tasks

We use ground truth event type and gold-standard trigger words to perform
Event Argument Extraction.

##### Dataset

We evaluate our performance of EAE on the English subset of Automatic Content
Extraction 2005 dataset
(ACE05-E)888https://www.ldc.upenn.edu/collaborations/past-projects/ace
Doddington et al. (2004). We follow Wadden et al. (2019); Lin et al. (2020)
for dataset processing. ACE05-E has hierarchical event types with 8 parent
types and 33 child types. Among all child types, roughly half of the event
types (14 out of 33) in ACE05-E have less than 50 event instances in the
training set. We show statistics for each event type in Table A.4.

##### Evaluation metrics

We use Argument F1-score following prior work Ji and Grishman (2008); Li et
al. (2021); Hsu et al. (2022): We consider an argument to be correctly
identified when the head word span of predicted text999We find the span of
predicted text in the given sentence, then use spacy library to find its head
word. matches that of the human-annotated text (denoted as Arg-I); We consider
an argument to be correctly classified if the role (e.g., agent) of a
_correctly identified_ argument matches that of the human annotation (denoted
as Arg-C).

Table 3: Performance of the code prompt on the Arg-I and Arg-C metrics and its
F1 score difference $\Delta_{C-T}^{(i)}$ with two text prompt variants
described in §4.2 (i.e.,
$\text{F1}_{\text{code}}-\text{F1}_{\text{text}}^{(i)}$). On Arg-C, there is a
trend that the code prompt performs better (i.e., $\Delta_{C-T}^{(i)}>0$) when
more in-context examples are provided, except on text-davinci-003.

Model | code-davinci-002 | text-davinci-002 | text-davinci-003
---|---|---|---
$k$-shot | Arg-I | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$ | Arg-C | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$ | Arg-I | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$ | Arg-C | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$ | Arg-I | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$ | Arg-C | $\Delta_{C-T}^{(1)}$ | $\Delta_{C-T}^{(2)}$
0 | 50.6 |  0.7 | 50.6 | 36.0 |  -2.2 | 36.0 | 48.9 |  -2.6 | 20.2 | 35.0 |  -2.4 | 13.1 | 49.9 |  -2.1 | 15.3 | 37.8 |  -1.4 | 12.6
1 | 57.3 |  0.1 |  4.7 | 47.8 |  -1.0 |  4.7 | 55.8 |  1.8 |  5.3 | 45.2 |  3.0 |  4.9 | 56.0 |  -1.5 |  1.1 | 44.7 |  -3.2 |  1.1
5 | 58.0 |  1.1 |  1.9 | 52.5 |  2.9 |  1.1 | 56.0 |  -2.0 |  1.0 | 48.8 |  3.0 |  1.4 | 59.2 |  -0.9 |  -0.7 | 51.7 |  1.4 |  -2.1
10 | 57.2 |  -1.4 |  -0.2 | 52.8 |  0.8 |  0.1 | 60.6 |  2.7 |  2.9 | 53.9 |  6.4 |  5.0 | 62.8 |  3.1 |  0.6 | 56.3 |  5.0 |  -1.2
20 | 62.1 |  1.7 |  0.2 | 58.5 |  3.6 |  2.4 | 59.9 |  0.9 |  3.7 | 56.5 |  8.0 |  5.8 | 65.0 |  3.5 |  0.7 | 60.4 |  7.8 |  -0.4

###  4.2 Comparison with Text Prompt

To compare our code-based prompt with text-based prompts, we design two
variants of text prompt: $T^{(1)}$ mimicking our code prompt (i.e., code
imitation, Figure A.5) and $T^{(2)}$ following BART-Gen style prompt Li et al.
(2021) (Figure A.6) which resembles natural language more compared to
$T^{(1)}$. Both text prompts have similar components as our code-based prompt
in Figure 2. Text prompts rely on natural language to define the requirement
and format of the desired output, while the code prompt utilizes PL syntax. We
compare the F1 score difference between the code prompt (§2) and two variants
of text prompts (i.e.,
$\Delta_{C-T}^{(i)}=\text{F1}_{\text{code}}-\text{F1}_{\text{text}}^{(i)},i\in\\{1,2\\}$)
on different LLMs in Table 3. We include exact performance numbers of text
prompts in Table A.3. We summarize our findings as follows:

  * •

Code prompt outperforms both text prompts on Arg-C F1 (i.e.,
$\Delta_{C-T}^{(i)}>0$) for two text prompt variants and all LLMs except text-
davinci-003 when sufficient in-context examples are given (i.e., $k\geq 5$).

  * •

For *-davinci-002 LLMs, there are more significant performance gains from
using a code prompt (i.e., increasing $\Delta_{C-T}^{(i)}$ for all $i$) when
the number of in-context examples $k$ increases (for $k\geq 5$).

  * •

There is no clear trend on Arg-I F1 to differentiate code and text prompts,
except for text-davinci-003, which exhibits similar behavior that code prompt
performs better with larger $k$.

  * •

Text prompt $T^{(2)}$ (BART-Gen style), which resembles natural language more,
performs poorly under low-shot ($k\leq 1$), primarily due to the LLM being
unable to produce the desired structure output described using language in
$T^{(2)}$, causing the low-shot code-text performance gap $\Delta_{C-T}^{(2)}$
to be larger compared to $T^{(1)}$. These low-shot performance differences
between $T^{(1)}$ and $T^{(2)}$ further signify the need to prompt engineering
for language-based prompts to work well in a low-shot setting.

###  4.3 Comparison with different LLM

We measure the performance of the same code prompt across different
foundational LLMs in §4.1. LLM performance comparison can be found in Figure
3. text-davinci-002 is an InstructGPT Ouyang et al. (2022) model finetuned
with human demonstrations based on code-davinci-002, yet these two LLMs
perform similarly in Arg-C F1. Although having a similar code prompt Arg-C
performance, text-davinci-002 generally has a larger $\Delta_{C-T}^{(i)}$
compared to code-davinci-002 of the same $k$ in Table 3 (e.g., +3.6 vs. +8.0,
+2.4 vs. +5.8 on 20-shot for both text prompt variants), suggesting the
degradation of text prompt performance after finetuning with human
demonstrations.

text-davinci-003, which uses reinforcement learning (RL) with reward models to
align with human preference101010https://beta.openai.com/docs/model-index-for-
researchers Ouyang et al. (2022), outperforms other LLMs for $k>5$. In Table
3, text-davinci-003 obtains superior Arg-C F1 performance (60.4% vs. 56.5% on
20-shot) compared to text-davinci-002. This suggests RL with reward models
effectively improves EAE performance (i.e., Arg-C) on code prompt.

Interestingly, text-davinci-003 has a very different $\Delta_{C-T}^{(i)}$
pattern for text prompt $T^{(2)}$ compared to $T^{(1)}$. Like text-
davinci-002, in Table 3, Arg-C $\Delta_{C-T}^{(1)}$ for text prompt $T^{(1)}$
has an increasing trend with a similar magnitude (e.g., $+7.8$ vs. $+8.0$ on
20-shot). That is, in both LLMs, the code prompt is always better than text
prompt $T^{(1)}$ with $k\geq 5$. However, for text prompt $T^{(2)}$ which is
more similar to natural sentences, the gap $\Delta_{C-T}^{(2)}$ exhibits a
vastly different pattern compared to other models: code prompt performs on par
or even slightly worse than $T^{(2)}$ for $k\geq 5$. We also notice that for
zero-shot prediction, $T^{(2)}$ on text-davinci-003 performs better compared
to other LLMs. This indicates that aligning LLM with RL and reward models
helps improve LLM’s ability to follow zero-shot language instructions.

Even though code prompt still performs superior to both text prompt variants
on 002 LLMs, results from text-davinci-003 suggest a better-aligned language
model can perform equally well on a natural text prompt $T^{(2)}$ when
sufficient in-context examples are provided.

Figure 3:  performance (in F1%) with different $k$. We observe improvements
with diminishing returns when we increase the number of in-context examples.
Exact performance numbers can be found in Table A.3 (code prompt). We stop at
$k=20$ for text-davinci and $k=50$ for code-davinci-002 as including more
examples would exceed the input length limitation imposed by corresponding
LLM.

###  4.4 Comparison with different $k$

We examine the performance of code prompts with varying numbers of examples in
Figure 3. We observe that F1 scores for all metrics generally increase with
diminishing returns when providing more in-context learning examples. The
initial in-context example ($k=1$) brings the largest absolute performance
gain (+11.8, +10.2, +6.9 Arg-C F1 for three LLMs). For $k\geq 20$ on code-
davinci-002, the Arg-I and Arg-C performance plateaus or even slightly
degrade, as not all event types have enough in-context examples to benefit
from increasing $k$ (i.e., only 19 out of 33 event types have more than 50
examples for in-context learning). To further investigate why the performance
plateaus, we analyze how the sentence variability (or diversity) of in-context
examples influences Arg-C performance in §A.4; We find that Arg-C performance
is positively correlated with the variability of in-context examples which
plateaus as $k$ increases, hinting that in-context learning performance may
eventually plateau with increasing $k$ due to little variability gains from
the additional data.

###  4.5 Comparison with Supervised Models

##### Baselines

Unlike prior methods trained on the entire training set, learns from up to 50
examples (i.e., 39 examples per event type on average, roughly 1% among all
training instances) to predict arguments for each test event type. To ensure a
fair comparison, for each event type t in the test set, we train a Text2Event
model Lu et al. (2021) and a DEGREE model (SOTA, Hsu et al. (2022)) on 20-shot
and 50-shot in-context examples used while providing gold-standard trigger
words. We evaluate both models trained on event type t on a partition of the
test set that only contains instances of event type t. We then aggregate F1
scores (micro F1) across all 31 event types on the test set and report them in
Table 4. Following Hsu et al. (2022), we also compare with classification-
based (DyGIE++ Wadden et al. (2019), BERT_QA Du and Cardie (2020), OneIE Lin
et al. (2020)) or generation-based (TANL Paolini et al. (2021), BART-Gen Li et
al. (2021), DEGREE Hsu et al. (2022)) models trained on the full training set.

##### Results

We report the performance of using LLMs (§4.1) in comparison with prior work
in Table 4. We report the performance of supervised models using the full
dataset from Hsu et al. (2022). Note that 50-shot results for text-davinci are
not available as the 50-shot input prompt will exceed LLM’s input token length
limitation, hence we use code-davinci-002 for 50-shot comparison.

In the few-shot setting, 20-shot using text-davinci-003 can surpass DEGREE Hsu
et al. (2022), the current state-of-the-art, by a large margin (+29.5% Arg-C
F1). Our zero-shot using the best-performing text-davinci-003 model can
already achieve higher Arg-I and Arg-C performance than the 20-shot and
50-shot DEGREE. Despite only learning from 20 examples, 20-shot achieves
comparable performance with other fully-supervised models trained on 100% of
the training data (4,202 instances).

Model | Data | Arg-I F1 | Arg-C F1
---|---|---|---
DyGIE++ | Full | 66.2 | 60.7
BERT-QA | Full | 68.2 | 65.4
OneIE | Full | 73.2 | 69.3
TANL | Full | 65.9 | 61.0
BART-Gen | Full | 69.9 | 66.7
DEGREE | Full | 76.0 | 73.5
$\textbf{\CodeForStruct}_{\texttt{text-davinci-003}}$ | 0-shot | 49.9 | 37.8
Text2Event | 20-shot* | 23.1 | 19.1
DEGREE | 20-shot* | 33.0 | 30.9
$\textbf{\CodeForStruct}_{\texttt{text-davinci-003}}$ | 20-shot* | 65.0 | 60.4
Text2Event | 50-shot* | 30.6 | 26.0
DEGREE | 50-shot* | 40.8 | 37.3
$\textbf{\CodeForStruct}_{\texttt{code-davinci-002}}$ | 50-shot* | 62.3 | 58.1

Table 4: Performance (in F1%) comparison between best-performing LLM and
existing supervised approaches. Performance numbers for all LLMs can be found
in Table A.3. *Some event types do not have 20 or 50 examples for in-context
learning; on average, we have 39 examples per type for a 50-shot prompt and 18
examples per type for 20-shot.

###  4.6 Event Type Hierarchy Improves Zero-resource EAE

In this section, we show that , when provided with hierarchical event
definitions and few-shot training instances $D_{e_{s}}$ from a sibling event
type $e_{s}\in\text{Siblings}(e)$ under the same parent event type, can
improve performance for child event type $e$ as good as if training instances
$D_{e}$ from the same event type $e$ were used. This allows zero-resource
event types without annotated data to exploit the event type hierarchy and
benefit from their high-resource siblings. We include an example task prompt
with sibling examples in Figure A.11 and report our results in Table 5.

##### Setup

We split the child types for each parent type into training and testing types
by selecting the high-resource child type with the largest amount of training
instances to be the training type and have the rest be testing types. The
train-test split for ACE types can be found in Table A.5. Under the same
parent event type, we use data instances from the training type (i.e., a
sibling of testing types) as in-context examples to predict arguments for each
testing type. We include event class definition (Figure 2) for parent event
type (e.g., Transaction), child training (sibling) event type (e.g.,
Transfer_Money), and child testing event type (e.g., Transfer_Ownership). We
show an example of event definition with sibling type in Figure A.10. The few-
shot performance when using data from a sibling type $D_{e_{s}}$ is denoted
with (sibling type) in Table 5. To demonstrate the effectiveness of using data
from sibling event types, we compare it with using training instances from the
testing event type itself $D_{e}$ (denoted as (same type)) and from a random
non-sibling event type (denoted as (non-sibling type)).

| Arg-I | Arg-C
---|---|---
0-shot | 52.8 | 42.9
1-shot (same type) | 54.3 | 50.2
1-shot (sibling type) | 57.2 | 51.9
1-shot (non-sibling type) | 56.3 | 50.3
10-shot (same type) | 58.7 | 55.2
10-shot (sibling type) | 60.8 | 54.9
10-shot (non-sibling type) | 58.5 | 51.0

Table 5:  code-davinci-002 performance (in F1%) when using examples from the
same, sibling or non-sibling event types for in-context learning. To ensure a
fair comparison, F1 scores are aggregated from 23 test event types in Table
A.5 that contains more than 10 training instances.

##### Results

We observe that , when prompted with training examples from sibling type,
performs on par with the prompt that uses training examples from the testing
type itself on 1-shot and 10-shot. The substantial performance gain (+9% Arg-C
F1 on 1-shot, +12% Arg-C F1 on 10-shot, compared with 0-shot) contributed by
sibling-type training examples demonstrate the potential of applying to zero-
resource event types with no training data by exploiting their hierarchical
relationship with other high-resource event types. Surprisingly, similar to
the observation made by Min et al. (2022), using in-context examples from a
random non-sibling type also benefits performance, albeit not as helpful as
sibling examples under 10-shot.

##  5 Related Work

##### Code-LLM for Structured Task

Sun et al. (2019); Singh et al. (2022) focus on procedural tasks that aim to
control situated agents in an embodied environment by representing the
procedure plan in code. Madaan et al. (2022) uses Code-LLM to generate a
structured commonsense reasoning graph represented in code, which is similar
in spirit to our work but in a different task. Gao et al. (2022) tackles math
and symbolic reasoning tasks by decomposing the natural language problem into
runnable steps using Code-LLM and delegating solution calculation to a PL
interpreter. We leverage PL features (e.g., inheritance, type annotation) to
introduce extra information and constraints for structured prediction, which
is largely overlooked by prior work.

##### Event Extraction

Li et al. (2013); Nguyen et al. (2016); Yang and Mitchell (2016); Wadden et
al. (2019); Lin et al. (2020) use classification models and mitigate error
propagation from pipeline models by leveraging global features to predict
event triggers and arguments jointly. Recent work such as Liu et al. (2020)
formulates event extraction as a reading comprehension problem and Li et al.
(2021); Huang et al. (2021); Paolini et al. (2021); Hsu et al. (2022) converts
event extraction to a text generation task to better exploit label semantics
from pretrained language models. The most similar work to ours is Text2Event
Lu et al. (2021), which uses controlled generation to generate structures in a
manually specified linearized format directly, hindering the model in
leveraging pre-trained NL knowledge. On the other hand, our approach directly
generates structure in PL instead of using a manually designed format to fully
exploit LLM’s knowledge of PL.

##  6 Conclusions and Future Work

We propose for structured prediction tasks in NLP by leveraging LLMs trained
on language and code. As a case study, we use to extract event arguments from
natural language sentences through code generation. We show that, with
sufficient in-context examples, formulating EAE as a code generation problem
is advantageous over using text-based prompts. Our proposed rivals fully-
supervised models trained on 4,202 data instances only using 20-shot. It also
outperforms a SOTA model by 29.5% absolute F1 when both are given the same
20-shot data. Furthermore, benefitting from hierarchical event definitions,
can predict arguments for zero-resource event types only using 10-shot
training instances from its sibling event type and outperforms 0-shot baseline
by 12% absolute F1 score. Going forward, we plan to expand to a broader range
of more complex structured prediction tasks (e.g., relation prediction, schema
matching). We would further explore the executable nature of PL to improve
LLM’s ability for structured prediction.

## Limitations

In this work, our approach assumes event triggers and argument templates
(i.e., ontology) are given. This limits our approach’s applicability, as it
requires an event detection system to produce event triggers and event types
before LLMs can be prompted to generate event arguments.

We only explore hierarchical events with only 2 levels from the ACE05-E
ontology and data, which has limited coverage of real-world complex event
hierarchy. Similar to prior event argument extraction work, our approach
relies on a human-curated hierarchical ontology. We leave automatically
discover hierarchical ontology for future work.

Despite LLMs performing well on EAE with few-shot data, compared to existing
supervised approaches, their inference is relatively slow and costly111111We
perform most of our experiments on code-davinci-002 which is in free public
beta at the time of the experiment. For text-davinci models, around 700 USD
was used to access its API to perform relevant experiments in this paper.
since the LLMs we used are generally more than 100x larger in the number of
parameters. Prior work Zhao et al. (2021); Lu et al. (2022) has demonstrated a
strong relationship between performance and in-context demonstrations;
however, for ease of comparison to supervised baselines, we use the same set
of examples from the training set for in-context learning. We expect better
selecting Liu et al. (2021) and ordering Lu et al. (2022) in-context examples
can benefit performance, which we leave for future work.

## Ethical Considerations

Since event argument extraction only requires predicting arguments from the
given text, the risk of generating toxic languages is relatively low as long
as the given test is not toxic. This is because the prediction can be grounded
in the input sentence, eliminating potential toxic tokens that did not appear
in the original sentence. However, discrimination and bias are possible, as
observed in the foundational LLMs we used Brown et al. (2020); Chen et al.
(2021); Ouyang et al. (2022), which we refer to Brown et al. (2020) for
detailed discussion.

## Acknowledgement

We thank the anonymous reviewers for their helpful suggestions and comments.
This research is based upon work supported by U.S. DARPA KAIROS Program No.
FA8750-19-2-1004, U.S. DARPA AIDA Program No. FA8750-18-2-0014 and U.S. DARPA
ITM Program No. FA8650-23-C-7316. The views and conclusions contained herein
are those of the authors and should not be interpreted as necessarily
representing the official policies, either expressed or implied, of DARPA, or
the U.S. Government. The U.S. Government is authorized to reproduce and
distribute reprints for governmental purposes notwithstanding any copyright
annotation therein.

## References

  * Banarescu et al. (2013) Laura Banarescu, Claire Bonial, Shu Cai, Madalina Georgescu, Kira Griffitt, Ulf Hermjakob, Kevin Knight, Philipp Koehn, Martha Palmer, and Nathan Schneider. 2013\.  Abstract Meaning Representation for sembanking.  In _Proceedings of the 7th Linguistic Annotation Workshop and Interoperability with Discourse_ , pages 178–186, Sofia, Bulgaria. Association for Computational Linguistics.
  * Brown et al. (2020) Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020.  Language models are few-shot learners.  _Advances in neural information processing systems_ , 33:1877–1901.
  * Chen et al. (2021) Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021.  Evaluating large language models trained on code.  _arXiv preprint arXiv:2107.03374_.
  * Chowdhery et al. (2022) Aakanksha Chowdhery, Sharan Narang, Jacob Devlin, Maarten Bosma, Gaurav Mishra, Adam Roberts, Paul Barham, Hyung Won Chung, Charles Sutton, Sebastian Gehrmann, et al. 2022.  Palm: Scaling language modeling with pathways.  _arXiv preprint arXiv:2204.02311_.
  * Doddington et al. (2004) George Doddington, Alexis Mitchell, Mark Przybocki, Lance Ramshaw, Stephanie Strassel, and Ralph Weischedel. 2004.  The automatic content extraction (ACE) program – tasks, data, and evaluation.  In _Proceedings of the Fourth International Conference on Language Resources and Evaluation (LREC’04)_ , Lisbon, Portugal. European Language Resources Association (ELRA).
  * Du and Cardie (2020) Xinya Du and Claire Cardie. 2020.  Event extraction by answering (almost) natural questions.  In _Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP)_ , pages 671–683, Online. Association for Computational Linguistics.
  * Gao et al. (2022) Luyu Gao, Aman Madaan, Shuyan Zhou, Uri Alon, Pengfei Liu, Yiming Yang, Jamie Callan, and Graham Neubig. 2022.  Pal: Program-aided language models.  _ArXiv_ , abs/2211.10435.
  * Halkidi et al. (2001) Maria Halkidi, Yannis Batistakis, and Michalis Vazirgiannis. 2001.  On clustering validation techniques.  _Journal of Intelligent Information Systems_ , 17:107–145.
  * Hoffmann et al. (2022) Jordan Hoffmann, Sebastian Borgeaud, Arthur Mensch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford, Diego de Las Casas, Lisa Anne Hendricks, Johannes Welbl, Aidan Clark, et al. 2022.  Training compute-optimal large language models.  _arXiv preprint arXiv:2203.15556_.
  * Hsu et al. (2022) I-Hung Hsu, Kuan-Hao Huang, Elizabeth Boschee, Scott Miller, Prem Natarajan, Kai-Wei Chang, and Nanyun Peng. 2022.  DEGREE: A data-efficient generation-based event extraction model.  In _Proceedings of the 2022 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 1890–1908, Seattle, United States. Association for Computational Linguistics.
  * Huang et al. (2021) Kung-Hsiang Huang, Sam Tang, and Nanyun Peng. 2021.  Document-level entity-based extraction as template generation.  In _Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing_ , pages 5257–5269, Online and Punta Cana, Dominican Republic. Association for Computational Linguistics.
  * Ji and Grishman (2008) Heng Ji and Ralph Grishman. 2008.  Refining event extraction through unsupervised cross-document inference.  In _In Proceedings of the Annual Meeting of the Association of Computational Linguistics (ACL 2008). Ohio, USA_.
  * Li et al. (2013) Qi Li, Heng Ji, and Liang Huang. 2013.  Joint event extraction via structured prediction with global features.  In _Proceedings of the 51st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)_ , pages 73–82, Sofia, Bulgaria. Association for Computational Linguistics.
  * Li et al. (2021) Sha Li, Heng Ji, and Jiawei Han. 2021.  Document-level event argument extraction by conditional generation.  In _Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 894–908, Online. Association for Computational Linguistics.
  * Lin et al. (2020) Ying Lin, Heng Ji, Fei Huang, and Lingfei Wu. 2020.  A joint neural model for information extraction with global features.  In _Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics_ , pages 7999–8009, Online. Association for Computational Linguistics.
  * Liu et al. (2021) Jiachang Liu, Dinghan Shen, Yizhe Zhang, Bill Dolan, Lawrence Carin, and Weizhu Chen. 2021.  What makes good in-context examples for gpt-3?  In _Workshop on Knowledge Extraction and Integration for Deep Learning Architectures; Deep Learning Inside Out_.
  * Liu et al. (2020) Jian Liu, Yubo Chen, Kang Liu, Wei Bi, and Xiaojiang Liu. 2020.  Event extraction as machine reading comprehension.  In _Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP)_ , pages 1641–1651, Online. Association for Computational Linguistics.
  * Lu et al. (2022) Yao Lu, Max Bartolo, Alastair Moore, Sebastian Riedel, and Pontus Stenetorp. 2022\.  Fantastically ordered prompts and where to find them: Overcoming few-shot prompt order sensitivity.  In _Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)_ , pages 8086–8098, Dublin, Ireland. Association for Computational Linguistics.
  * Lu et al. (2021) Yaojie Lu, Hongyu Lin, Jin Xu, Xianpei Han, Jialong Tang, Annan Li, Le Sun, Meng Liao, and Shaoyi Chen. 2021.  Text2Event: Controllable sequence-to-structure generation for end-to-end event extraction.  In _Proceedings of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (Volume 1: Long Papers)_ , pages 2795–2806, Online. Association for Computational Linguistics.
  * Madaan et al. (2022) Aman Madaan, Shuyan Zhou, Uri Alon, Yiming Yang, and Graham Neubig. 2022.  Language models of code are few-shot commonsense learners.  _arXiv preprint arXiv:2210.07128_.
  * Miller (1981) L. A. Miller. 1981.  Natural language programming: Styles, strategies, and contrasts.  _IBM Systems Journal_ , 20(2):184–215.
  * Min et al. (2022) Sewon Min, Xinxi Lyu, Ari Holtzman, Mikel Artetxe, Mike Lewis, Hannaneh Hajishirzi, and Luke Zettlemoyer. 2022.  Rethinking the role of demonstrations: What makes in-context learning work?  _ArXiv_ , abs/2202.12837.
  * Nguyen et al. (2016) Thien Huu Nguyen, Kyunghyun Cho, and Ralph Grishman. 2016.  Joint event extraction via recurrent neural networks.  In _Proceedings of the 2016 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 300–309, San Diego, California. Association for Computational Linguistics.
  * Nijkamp et al. (2022) Erik Nijkamp, Bo Pang, Hiroaki Hayashi, Lifu Tu, Huan Wang, Yingbo Zhou, Silvio Savarese, and Caiming Xiong. 2022.  A conversational paradigm for program synthesis.  _arXiv preprint_.
  * Ouyang et al. (2022) Long Ouyang, Jeff Wu, Xu Jiang, Diogo Almeida, Carroll L. Wainwright, Pamela Mishkin, Chong Zhang, Sandhini Agarwal, Katarina Slama, Alex Ray, John Schulman, Jacob Hilton, Fraser Kelton, Luke E. Miller, Maddie Simens, Amanda Askell, Peter Welinder, Paul Francis Christiano, Jan Leike, and Ryan J. Lowe. 2022\.  Training language models to follow instructions with human feedback.  _ArXiv_ , abs/2203.02155.
  * Paolini et al. (2021) Giovanni Paolini, Ben Athiwaratkun, Jason Krone, Jie Ma, Alessandro Achille, Rishita Anubhai, Cicero Nogueira dos Santos, Bing Xiang, and Stefano Soatto. 2021\.  Structured prediction as translation between augmented natural languages.  _arXiv preprint arXiv:2101.05779_.
  * Sebrechts and Gross (1985) Marc M. Sebrechts and Paul Gross. 1985.  Programming in natural language: A descriptive analysis.  _Behavior Research Methods, Instruments, & Computers_, 17:268–274.
  * Singh et al. (2022) Ishika Singh, Valts Blukis, Arsalan Mousavian, Ankit Goyal, Danfei Xu, Jonathan Tremblay, Dieter Fox, Jesse Thomason, and Animesh Garg. 2022.  ProgPrompt: Generating situated robot task plans using large language models.
  * Sun et al. (2019) Shao-Hua Sun, Te-Lin Wu, and Joseph J Lim. 2019.  Program guided agent.  In _International Conference on Learning Representations_.
  * Wadden et al. (2019) David Wadden, Ulme Wennberg, Yi Luan, and Hannaneh Hajishirzi. 2019.  Entity, relation, and event extraction with contextualized span representations.  In _Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP)_ , pages 5784–5789, Hong Kong, China. Association for Computational Linguistics.
  * Yang and Mitchell (2016) Bishan Yang and Tom M. Mitchell. 2016.  Joint extraction of events and entities within a document context.  In _Proceedings of the 2016 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 289–299, San Diego, California. Association for Computational Linguistics.
  * Zhang and Ji (2021) Zixuan Zhang and Heng Ji. 2021.  Abstract Meaning Representation guided graph encoding and decoding for joint information extraction.  In _Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies_ , pages 39–49, Online. Association for Computational Linguistics.
  * Zhao et al. (2021) Tony Zhao, Eric Wallace, Shi Feng, Dan Klein, and Sameer Singh. 2021.  Calibrate before use: Improving few-shot performance of language models.  _ArXiv_ , abs/2102.09690.

##  Appendix A Appendix

###  A.1 Qualitative Analysis

Figure A.1: Examples of 0-shot and 50-shot event argument prediction using
code-davinci-002 on ACE05-E. In both 0-shot examples, LLM can infer an entity
that does not present in the text as an argument (marked with a yellow span).
predicts fewer arguments when the examples are increased to 50-shot. We mark
incorrect predictions with strikethrough text. Entities that LLM failed to
predict are marked in red font.

We show examples of 0-shot and 50-shot argument extraction result in Figure
A.1. can leverage implicit commonsense knowledge in LLM to infer arguments not
presented in the text. In the first 0-shot example, the model inferred the
place of Welch’s retirement is in the United States. This is a reasonable
guess since Welch, in this example, is the former CEO of General Electric
(GE), whose headquarter is in the United States. In the second 0-shot example,
our model inferred that the Justice:Fine event should take place in a court,
which matches our commonsense knowledge. Interestingly, we observe that
increasing the number of in-context examples from 0-shot to 50-shot inhibits
LLM from generating arguments (i.e., making LLMs more conservative), including
these inferred arguments and a correctly predicted argument (i.e., SEC) in
0-shot predictions.

| Arg-I F1 | Arg-C F1
---|---|---
$k$-shot | 0 | 1 | 10 | 20 | 50 | 0 | 1 | 10 | 20 | 50
| 50.6 | 57.3 | 57.2 | 62.1 | 62.3 | 36.0 | 47.8 | 52.8 | 58.5 | 58.1
\+ amr | 51.1 | 54.7 | 55.6 | - | - | 37.2 | 44.2 | 51.3 | - | -
\+ keywords | 52.3 | 57.3 | 58.0 | 61.7 | 61.7 | 36.4 | 47.3 | 53.5 | 57.7 | 57.9

Table A.1: Prompt components analysis on code-davinci-002. The best scores (in
%) are bolded. - means the result is unavailable due to the input prompt
exceeding the corresponding LLM’s supported input token length.

###  A.2 Prompt Component Analysis

In this section, we present an empirical analysis of other prompt component
candidates. We compare different prompt components in Table A.1 using code-
davinci-002 and following the same hyper-parameters described in §4.1.

  * •

Event Keywords We augment event-related keywords into the docstring of event
definition for (illustrated in Figure A.8). We follow the same keywords used
by Li et al. (2021).

  * •

AMR Zhang and Ji (2021) have demonstrated the effectiveness of utilizing
Abstract Meaning Representation (AMR) Banarescu et al. (2013) for information
extraction. We experiment with AMR-augmented prompts. We use armlib
121212https://github.com/bjascob/amrlib, parse_xfm_bart_large v0.1.0 to
predict AMR, and append the AMR structure after the NL sentence in the task
prompt §2.2 (see Figure A.7 for an example).

Prompts that include event keywords and AMR all perform slightly better than
under the zero-shot setting on all metrics (Table A.1).

| Arg-I F1 | Arg-C F1
---|---|---
$k$-shot | 0 | 1 | 10 | 20 | 50 | 0 | 1 | 10 | 20 | 50
| 50.6 | 57.3 | 57.2 | 62.1 | 62.3 | 36.0 | 47.8 | 52.8 | 58.5 | 58.1
\- trigger | 48.8 | 54.4 | 53.0 | 57.6 | 56.6 | 33.8 | 44.1 | 48.9 | 53.8 | 51.5
\- description | 51.4 | 56.7 | 56.2 | 61.1 | 61.6 | 36.1 | 47.2 | 51.6 | 57.1 | 57.8
\- type annotation | 49.4 | 57.2 | 58.0 | 61.5 | 61.4 | 35.7 | 48.0 | 54.5 | 57.6 | 57.5
\- hierarchy | 49.4 | 56.6 | 55.5 | 59.9 | 60.4 | 34.3 | 46.8 | 50.0 | 55.4 | 55.9

Table A.2: Ablation study on code-davinci-002. The best scores (in %) are
bolded. - means the result is unavailable due to the input prompt exceeding
the corresponding LLM’s supported input token length.

###  A.3 Ablation Study

In Table A.2, we ablate different prompt components described in §2, including
event trigger marking, event description in natural language, type annotation,
and hierarchical ontology. We perform this ablation study using code-
davinci-002.

##### Event Trigger Marking

We find that removing event trigger marking consistently degrades performance
on all metrics over varying numbers of in-context examples.

##### Event Description

Event descriptions generally provide a small F1 gain under the few-shot
setting. However, removing event descriptions improves ’s zero-shot
performance on argument identification. 0-shot Arg-I precision is relatively
unchanged after removing event descriptions (37.4 vs. 37.2). We argue that
removing event descriptions loosens entity-related constraints and allows LLM
to identify more relevant entities. This is supported by the improvement of
0-shot Arg-I recall (78.7 to 81.8) after description removal, which mainly
accounts for the increase in 0-shot Arg-I F1. Despite being helpful in
argument identification by boosting 0-shot Arg-I recall, we do not see the
benefit of removing descriptions in few-shot Arg-C, where it performs
consistently worse compared to .

##### Type Annotation

Type annotation is more helpful when more in-context examples are provided
($k\geq 20$). Under a low-shot setting, the F1 difference resulting from type
annotation removal is small and inconsistent across different shots. Prompts
with type annotation consistently outperforms prompts without it when
sufficient in-context examples are provided ($k\geq 20$). We hypothesize that
type annotations help disambiguate entity types accepted for each argument,
and such disambiguation ability is only needed when the number of entity
instances that appeared in in-context examples passes a certain threshold
(e.g., $k\geq 20$).

##### Hierarchical Event Definition

Providing hierarchical event definition (i.e., the parent class definition of
a given child event class) benefits performance in high-shot setting ($k\geq
20$). Prompts without parent class definition perform on par with under
$k<20$.

###  A.4 In-context Example Variability Analysis

Figure A.2:  The variability of $k$-shot in-context examples (i.e., average
euclidean distance from centroid example) across different event types
increases with diminishing returns when $k$ increases.

Figure A.3:  The variability of in-context examples is positively correlated
with code prompt Arg-C performance.

To investigate why the Arg-C performance plateaus with an increasing number of
in-context examples $k$ as shown in Figure 3, we analyze the sentence
variability of a fixed set of in-context examples (§2.3). We consider the set
of $k$-shot in-context examples for each event type $e$ as a cluster $D_{e}$
where $|D_{e}|\leq k$ and use sentence-transformer131313all-mpnet-base-v2
model to embed all the input sentences from $D_{e}$ into a cluster of vectors
$V_{e}$.

We use the average euclidean distance from the centroid example similar to
Halkidi et al. (2001) to measure the variability of in-context examples for
each event type $e$:

$\text{Variability}(e)=\frac{1}{|V_{e}|}\sum_{v\in V_{e}}d(v,\bar{v})$

where $d(\cdot,\cdot)$ is the euclidean distance between two vectors and
$\bar{v}=\frac{1}{|V_{e}|}\sum_{v\in V_{e}}v$ is the centroid example of the
cluster $V_{e}$.

We calculate the mean $\text{Variability}(e)$ across all $e$ for
$k\in\\{1,\cdots,50\\}$. In Figure A.2, similar to Arg-C performance in Figure
3, we find the mean $\text{Variability}(e)$ across all $e$ increases with
diminishing returns with increasing $k$. Furthermore, we find that, in Figure
A.3, Arg-C F1 performance is positively correlated with the mean
$\text{Variability}(e)$ across all $e$. This suggests the lack of in-context
example variability improvement could be one of the reasons Arg-C F1 plateaus,
even when more examples are given.

Figure A.4: Example prediction of 20-shot text prompt $T^{(1)}$ using text-
davinci-002 and code prompt using code-davinci-002. In this example, 20-shot
text prompt using text-davinci-002 incorrectly predicts the same entity Anne-
Marie as both adjudicator and plaintiff of the Justice:Sue event.

| Model | code-davinci-002 | text-davinci-002 | text-davinci-003
---|---|---|---|---
| Metric | Arg-I | Arg-C | Arg-I | Arg-C | Arg-I | Arg-C
Prompt |  $k$-shot |  |  |  |  |  |
code | 0 | 50.6 | 36.0 | 48.9 | 35.0 | 49.9 | 37.8
1 | 57.3 | 47.8 | 55.8 | 45.2 | 56.0 | 44.7
5 | 58.0 | 52.5 | 56.0 | 48.8 | 59.2 | 51.7
10 | 57.2 | 52.8 | 60.6 | 53.9 | 62.8 | 56.3
20 | 62.1 | 58.5 | 59.9 | 56.5 | 65.0 | 60.4
30 | 62.2 | 58.4 | - | - | - | -
50 | 62.3 | 58.1 | - | - | - | -
text (code imitation) | 0 | 49.9 | 38.2 | 51.5 | 37.4 | 52.0 | 39.2
1 | 57.2 | 48.8 | 54.0 | 42.2 | 57.5 | 47.9
5 | 56.9 | 49.6 | 58.0 | 45.8 | 60.1 | 50.3
10 | 58.6 | 52.0 | 57.9 | 47.5 | 59.7 | 51.3
20 | 60.4 | 54.9 | 59.0 | 48.5 | 61.5 | 52.6
text (BART-Gen style Li et al. (2021)) | 0 | 0.0 | 0.0 | 28.7 | 21.9 | 34.6 | 25.2
1 | 52.6 | 43.1 | 50.5 | 40.3 | 54.9 | 43.6
5 | 56.1 | 51.4 | 55.0 | 47.4 | 59.9 | 53.8
10 | 57.4 | 52.7 | 57.7 | 48.9 | 62.2 | 57.5
20 | 61.9 | 56.1 | 56.2 | 50.7 | 64.3 | 60.8

Table A.3: Performance of the code and two variants of the text prompts on the Arg-I and Arg-C metrics. 50-shot results for text-davinci and text prompts are unavailable since the 50-shot prompt length exceeds such LLM’s input token limitation. Examples of text prompt variants can be found in Figure A.5 (code imitation) and Figure A.6 (BART-Gen style).  Figure A.5: Natural language prompt for EAE task following our code prompt design described in section 2. We ask a LLM to generate event instantiation marked in green.  Figure A.6: BART-Gen style Li et al. (2021) natural language prompt for EAE task. We ask a LLM to generate event instantiation marked in green. Brackets and double-enclosed strings are designed for ease of parsing free form natural language.  Figure A.7: Example of an AMR-augmented task prompt. We append the AMR prediction after the input sentence. Different prompt components compared to are highlighted in yellow.  Figure A.8: Example of an event-keywords-augmented event definition. Different prompt components compared to are highlighted in yellow. We use event keywords from Li et al. (2021).  Figure A.9: Example of a hierarchical event definition. Different prompt components compared to are highlighted in yellow. Figure A.10: Example of a hierarchical event definition with a sibling event type. Different prompt components compared to Figure A.9 are highlighted in yellow. Figure A.11: Example of a task prompt with a 1-shot example from sibling event type. Event definitions for the task prompt is shown in Figure A.10. Groundtruth prediction is colored green.  |  | # of Test Instances | # of Train Example
---|---|---|---
Parent Event Type | Child Event Type |  |
Business | Declare-Bankruptcy | 2 | 39
End-Org | 5 | 24
Merge-Org | 0 | 13
Start-Org | 17 | 21
Conflict | Attack | 90 | 1211
Demonstrate | 7 | 62
Contact | Meet | 49 | 194
Phone-Write | 8 | 104
Justice | Acquit | 1 | 4
Appeal | 6 | 30
Arrest-Jail | 6 | 72
Charge-Indict | 8 | 95
Convict | 6 | 61
Execute | 2 | 12
Extradite | 1 | 6
Fine | 6 | 22
Pardon | 0 | 2
Release-Parole | 1 | 44
Sentence | 11 | 83
Sue | 4 | 60
Trial-Hearing | 5 | 103
Life | Be-Born | 3 | 44
Die | 17 | 516
Divorce | 9 | 20
Injure | 1 | 125
Marry | 10 | 71
Movement | Transport | 47 | 561
Personnel | Elect | 13 | 156
End-Position | 17 | 143
Nominate | 1 | 11
Start-Position | 11 | 87
Transaction | Transfer-Money | 12 | 121
Transfer-Ownership | 27 | 85
Table A.4: The number of Train/Test event instances for 33 event types in ACE05-E. Parent Event Type | Child Event Type (Train) | Child Event Type (Test)
---|---|---
Business | Declare-Bankruptcy | End-Org
Merge-Org*
Start-Org
Conflict | Attack | Demonstrate
Contact | Meet | Phone-Write
Justice | Trial-Hearing | Acquit
Appeal
Arrest-Jail
Charge-Indict
Convict
Execute
Extradite
Fine
Pardon*
Release-Parole
Sentence
Sue
Life | Die | Be-Born
Divorce
Injure
Marry
Personnel | Elect | End-Position
Nominate
Start-Position
Transaction | Transfer-Money | Transfer-Ownership
Table A.5: Train/Test split for each parent event type. * denotes child event
types that do not have examples in the ACE05-E test set.


# On Liquidity Mining for Uniswap v3

Jimmy Yin  izumi Finance<EMAIL_ADDRESS>and  Mac Ren  izumi Finance
<EMAIL_ADDRESS>
###### Abstract.

The recently proposed Uniswap v3 replaces the fungible liquidity provider
token (LP token) into non-fungible ones, making the design for liquidity
mining more difficult. In this paper, we propose a flexible liquidity mining
scheme that realizes the overall liquidity distribution through the fine
control of local rewards. From the liquidity provider’s point of view, the
liquidity provision strategy forms a multiplayer zero-sum game. We analyze the
Nash Equilibrium and the corresponding strategy, approximately, deploying the
liquidity proportional to the reward distribution, in some special cases and
use it to guide the general situations. Based on the strategic response above,
such a scheme allows the mining rewards provider to optimize the distribution
of liquidity for the purpose such as low slippage and price stabilization.

blockchain, decentralized finance, Uniswap v3, liquidity mining

††copyright: rightsretained

##  1\. Introduction

Decentralized finance (Defi) has made considerable progress in the past two
years and the decentralized exchange (DEX) is one of the most important parts,
which allows users to swap between two different tokens without a centralized
trusted intermediary. The leading project of DEX is undoubtedly Uniswap, which
uses the automated market maker  (AMM) mechanism to determine the price, or
equivalently the reserve curve, of an asset to the other in its v1 & v2
versions(Adams, 2018; Adams et al., 2020). The AMM design for Uniswap v1 & v2
is clean and neat, where the reserves $x$ and $y$ for the token $X$ and $Y$
satisfy the constant product formula $x\cdot y=k$, as shown in Fig. 1 with the
blue curve. When an user tries to swap $\Delta x$ of $X$ for $Y$, he will
receive $\Delta y$ derived from $(x+\Delta x)(y+\Delta y)=k$ without
considering the transaction fees.

Uniswap v1 & v2 suffer from the problem of low efficiency capital utilization,
since only a fraction of the assets in the pool are available for a given
price range. Recently, Uniswap v3 was proposed and launched, on Ethereum and
Optimism, with the concept of concentrated liquidity, where liquidity
providers can provide liquidity only to a certain price intervals, e.g.
$[p_{a},p_{b}]$. In the given price range, the reserves for $x$ and $y$ is
similar to the the constant product with adding “virtual” reserves
$L/\sqrt{p_{b}}$ and $L\sqrt{p_{a}}$:

$(x+L/\sqrt{p_{b}})(y+L\sqrt{p_{a}})=L^{2}.$

Geometrically, the reserve curve is shifted to intercept the axes, as shown in
Fig. 1 with the red line. The intercepts can be calculated by letting $x$ and
$y$ equal to zero respectively.

Figure 1. Illustration for the reserve curve for Uniswap v2 & v3. When the
liquidity is concentrated in price range $[p_{a},p_{b}]$, v3 adds “virtual”
liquidity to $X$ and $Y$ to maintain a constant product
$(x+x_{v})(y+y_{v})=k$.

If the constant product formula lays a solid foundation, the prosperity of the
DeFi ecosystem is inseparable from the innovative mechanism of liquidity
mining with the liquidity provider tokens (LP tokens). Inspired by the
Compound (Compound, 2021; Goyal, 2020) mining design, in August 2020, the
decentralized exchange Sushiswap started liquidity mining, and initially
subsidized Uniswap LP tokens staked on Sushiswap(Karaivanov, 2021), and then
launched a liquidity migration reward program for Sushiwap LP. The liquidity
mining mechanism created by Compound and Sushiswap solves the problem of early
liquidity provision and community expansion of the project, and has a great
inspiration on the development of DeFi ecology. After that, the token
distribution along with liquidity mining becomes the standard configuration of
DeFi projects.

The current standard liquidity mining mechanism needs the fungible property of
the LP tokens. However, in Uniswap v3(uniswapv3white), the LP token is non-
fungible. Specifically, when a liquidity provider deploy liquidity, he will
receive a non-fungible token(NFT), marking which price range and how much
liquidity he provides. The introduce of the non-fungible property is
essentially due to the independence of the liquidity in different price
ranges, making the design for liquidity mining more difficult. In this paper,
we propose a liquidity mining scheme for Uniswap v3, which realizes the
overall liquidity distribution through the fine control of the rewards
locally, while takes flexibility, fairness and stability in to consideration.
We theoretically analyze the strategic response both from the liquidity
providers side and the reward provider side.

###  1.1. Outline

Section 2 introduces parts of the Uniswap v3 protocol relating to the core
liquidity provision scheme. Section 3 introduces the framework of liquidity
mining design. In Section 4 we analyze the strategic response from the
perspective of the liquidity providers, and then how can a reward provider
makes use of it. Finally we conclude in Section 5.

##  2\. Liqudity Provision in Uniswap V3

Without further explanation, we consider one pool in the Uniswap V3 protocol
which consists of two kinds of tokens $X,Y$ and suppose the real reserves of
$X,Y$ are $x$ and $y$ respectively. In the context of AMMs, including Uniswap
V3, a protocol essentially describes a price curve which is dynamic as the
reserves change. We take $X$ as the base token and $Y$ as the quote one, and
the instantaneous price $p=dy/dx$ then represents how many $Y$ tokens can we
get with $dx\leavevmode\nobreak\ X$ tokens. For example, when $X$ is ETH and
$Y$ is USDC, currently the price $p$ ETH-USDC is fluctuating around $3000$
from the open market data.

Uniswap v3 introduces the concept of concentrated liquidity, which instead of
putting liquidity on the price range of $[0,\infty)$, as in Uniswap V2,
liquidity providers can provide their liquidity in a custom finite range
$[p_{a},p_{b}]$. When the price crosses the boundary of the range, one of the
reserves will be depleted.

For some practical considerations, the whole price space $[0,\infty)$ are
partitioned by discrete ticks into bins, following the below definition.

###### Definition 2.1 (ticks & bins).

When the pool is initialized with a price $p_{0}$, and a base step-size $d$,
e.g. $0.0001$, the $i$-th, tick is a price value that satisfies:

$p_{i}=p_{0}\cdot d^{i},\leavevmode\nobreak\ \leavevmode\nobreak\
i\in(-\infty,\infty).$

The $i$-th bin $b_{i}$ is the price range with two adjacent ticks $p_{i}$ and
$p_{i+1}$ as boundaries:

$b_{i}=[p_{i},p_{i+1}],\leavevmode\nobreak\ \leavevmode\nobreak\
i\in(-\infty,\infty).$

Suppose the current price $p=p_{c}$. For each bin $b_{i}$, the liquidity
providers can deploy their liquidity (tokens) into it. The liquidity is
measured by $\Delta L$. Suppose $p_{c}\in b_{j}$, that is $p_{j}\leq
p_{c}<p_{j+1}$, and the tokens needed for different bins $b_{i}$ with the same
liquidity value can be calculated by the following formula:

(1) $\displaystyle\Delta y$ $\displaystyle=\begin{cases}0&j<i\\\ \Delta
L\cdot(\sqrt{p_{c}}-\sqrt{p_{i}})&j=i\\\ \Delta
L\cdot(\sqrt{p_{i+1}}-\sqrt{p_{i}})&j>i\\\ \end{cases}$ $\displaystyle\Delta
x$ $\displaystyle=\begin{cases}\Delta
L\cdot(1/\sqrt{p_{i}}-1/\sqrt{p_{i+1}})&j<i\\\ \Delta
L\cdot(1/\sqrt{p_{c}}-1/\sqrt{p_{i+1}})&j=i\\\ 0&j>i\\\ \end{cases}$

Note that only in the bin $b_{j}$ containing the current price, need we deploy
both $X$ and $Y$ tokens. One key property is for a fixed bin $b_{i}$, the
tokens $\Delta X$ and $\Delta Y$ needed is linear to the liquidity $\Delta L$.

We denote the liquidity in each $b_{i}$ by $L_{i}$. The liquidity in different
bins are independent in some sense. First, liquidity providers can deploy the
liquidity on any bin without the influence of the others. Besides, when the
current price $p_{c}$ in $b_{j}$ and the price after swapping will not cross
the boundary, the procedure will only use the liquidity $L_{j}$ and leave the
others untouched. Even when the intermediate price crosses the boarder in the
swapping procedure, it just comes to another independent liquidity pool.

##  3\. Liquidity Mining Scheme

The design of the liquidity mining mechanism has effects on both the reward
provider, who provide reward tokens, and liquidity providers. Given a mining
rule, the game between the two players enables each to accomplish his own
goals. For the reward provider, typically the manager of at least one token in
the pool, the prime goal is to optimize the liquidity distribution to meet the
needs such as low slippage and price stabilization. For the liquidity
providers, the prime goal is to get as much rewards as they can.

In general, the strategy of a liquidity provider is determined both by the
mining reward policy and price trend forecasting. In this paper, we only
consider the first factor to simply the discussion. A proper design of the
liquidity mining should take the following aspects into consideration.

  1. (1)

Flexibility: the choice of different parameters of the scheme will have a
corresponding impact on the distribution of liquidity, enabling the reward
provider to optimize the liquidity distribution.

  2. (2)

Fairness: a rational liquidity provider should get a return that matches his
own capital.

  3. (3)

Stability: in the case of relatively stable market conditions, neither the
liquidity providers need to frequently adjust their liquidity allocation for
liquidity mining rewards, nor the reward provider need to adjust the scheme to
optimize the liquidity distribution.

First, the support of reward distribution should cover multiple bins in order
to meet the flexibility and stability requirements. Otherwise, one alternative
design is to only give rewards to the liquidity in one certain bin. For
example, the bin $b_{j}$ that is “active”, i.e., the current price $p_{c}$
lies in that bin. In that case, for the reward provider, the incentive has no
effect on the rest bins except $b_{j}$ and thus hard to optimize the overall
liquidity distribution. For the liquidity providers, obviously the optimal
provision strategy is to put all their liquidity on that bin. When the price
varies a little, i.e., even crosses one bin, the providers need to re-allocate
their liquidity to the new bin and thus not stable. Although a liquidity
provider can use a sub-optimal strategy that chooses a price range and places
the liquidity according to the range, there is only one bin can be rewarded,
lowing the efficiency of capital utilization.

Combining with the liquidity provision mechanism in Uniswap V3, where for a
fixed bin $b_{i}$, the liquidity is fungible due to the linearity. Besides,
the liquidity in different bins are relatively independent in the sense that
the liquidity procedure can specific a certain bin and the swapping procedure
in a bin will not impact the others. We can distribute the whole rewards on
some certain bins and in each bin, the rewards are distributed to the
liquidity providers proportional to their contributions.

We formalize and summarize the proposed liquidity mining scheme as follows.

###### Definition 3.1.

A feasible liquidity mining scheme is composed of the following:

  1. (1)

A set of bins $\mathcal{B}=\\{b_{i}|i\in\mathcal{I}_{b}\\}$, where liquidity
providers can get rewards if and only if they provide liquidity on these bins.

  2. (2)

A total reward token amount $R$ which is distributed at each time slot.

  3. (3)

A reward distribution for the reward tokens on the chosen bins $\mathcal{B}$.
Suppose the reward for the bin $b_{i}$ is $R_{i}$ at each time slot, it should
satisfy:

$\sum_{i\in\mathcal{I}_{b}}R_{i}=R.$

  4. (4)

Suppose the liquidity $L_{i}$ in bin $b_{i}$ is provided by $N$ liquidity
providers with the $k$-th one $L_{ik}$:

$\sum_{k=1}^{N}L_{ik}=L_{i},\leavevmode\nobreak\ \forall i\in\mathcal{I}_{b}.$

The reward to the $k$-th liquidity provider in $b_{i}$ at each time slot is
$V_{ik}=R_{i}\cdot\frac{L_{ik}}{L_{i}}$. Consequently, the overall reward
received by the $k$-th liquidity provider at each time slot is

$V_{k}=\sum_{i\in\mathcal{I}_{b}}R_{i}\cdot\frac{L_{ik}}{L_{i}},\leavevmode\nobreak\
\leavevmode\nobreak\ \forall k\in{1,...,N}$

##  4\. Analysis

As mentioned at the beginning of Section 3, a liquidity mining scheme has
effects on both the reward providers and liquidity providers. A comprehensive
analysis framework should cover both sides. Below we first analyze the
strategy in the Nash equilibrium the liquidity providers should apply based on
the scheme proposed in Section 3. Next we analyze how the strategy used by the
liquidity providers helps the reward providers optimize the liquidity
distribution.

###  4.1. The Liquidity Providers’ Perspective

We continue to use the settings and symbols from the previous sections. For
the $k$-th liquidity provider, suppose he has an amount $x_{k}$ of the $X$
token and $y_{k}$ of $Y$ respectively. Suppose each liquidity provider is
purely rational and the only goal for him is to maximize the revenue of
liquidity reward. We omit the fees required to provide liquidity to simplify
our discussion.

A liquidity provider need to find a distribution strategy placing his $X$ and
$Y$ tokens in to the bins. With the above assumptions, obviously, the $N$
liquidity providers form a multiplayer zero-sum game. We first show the
optimal strategy when the current price $p_{c}$ lies at the boundary of a bin,
i.e., $p_{c}=p_{i}$ for a certain $i$.

###### Theorem 4.1 (Nash Equilibrium).

With the assumptions above, the strategy described below for the liquidity
providers forms a Nash equilibrium.

  1. (1)

Based on the current price $p_{c}$, the bins are partitioned into two subsets
where $\mathcal{B}_{l}=\\{b_{i}|i\in\mathcal{I}_{l}\\}$ are the bins on the
left and $\mathcal{B}_{r}=\\{b_{i}|i\in\mathcal{I}_{r}\\}$ on the right.

  2. (2)

The $k$-th liquidity providers put the $X$ token proportional to the rewards
on $\mathcal{B}_{r}$, and put the $Y$ token proportional to the rewards on
$\mathcal{B}_{l}$. Specifically, for $b_{i}\in\mathcal{B}_{r}$, put
$x_{k}\cdot\dfrac{R_{i}}{\sum_{j\in\mathcal{I}_{r}}R_{j}}$ in it; for
$b_{i}\in\mathcal{B}_{l}$, put
$y_{k}\cdot\dfrac{R_{i}}{\sum_{j\in\mathcal{I}_{l}}R_{j}}$ in it.

With the strategy, the $k$-th liquidity provider will get
$\sum_{j\in\mathcal{I}_{r}}R_{j}\cdot\frac{x_{k}}{x}+\sum_{j\in\mathcal{I}_{l}}R_{j}\cdot\frac{y_{k}}{y}$
reward, where $x$ and $y$ are the total amount of the tokens the liquidity
providers put.

###### Proof.

Denote the accumulated reward on left bins $\mathcal{B}_{l}$ by $R_{l}$,
i.e.,$R_{l}=\sum_{j\in\mathcal{I}_{l}}R_{j}$ and $R_{r}$ on the right
similarly. We first exam the provision is valid. Since we have assumed the
current $p_{c}$ is on the boundary of a bin, the bin that requires the
liquidity provider deploy both $X$ and $Y$ tokens does not exist. According to
the liquidity provision rule Eq. 1, the liquidity provider can only deploy $X$
token in bins $\mathcal{B}_{r}$ and $Y$ token in bins $\mathcal{B}_{l}$, which
means that the distributions for $X$ and $Y$ tokens are independent.
Obviously,
$x_{k}=\sum_{i\in\mathcal{I}_{r}}x_{k}\cdot\dfrac{R_{i}}{\sum_{j\in\mathcal{I}_{r}}R_{j}}$
and
$y_{k}=\sum_{i\in\mathcal{I}_{l}}y_{k}\cdot\dfrac{R_{i}}{\sum_{j\in\mathcal{I}_{l}}R_{j}}$.

Next we check the strategy proposed above forms a Nash equilibrium. We can
discuss separately for $X$ and $Y$ because of the independence of the
distributions. We discuss the $X$ case and the conclusion can be obtained
similarly for $Y$. For the $k$-th liquidity provider, since the other
liquidity providers use the same proposed strategy and the linearity in Eq. 1,
we can treat the other liquidity providers as a $k^{\prime}$-th provider.
Denote $x_{k^{\prime}}=\sum_{i\in{1,...,N},i\not=k}x_{k}$. The $k^{\prime}$-th
liquidity provider place $x_{jk^{\prime}}=x_{k^{\prime}}\cdot R_{j}/R_{r}$ of
token $X$ on the bin $R_{j}$. Again, since the liquidity $L_{jk^{\prime}}$
added is linear to $x_{jk^{\prime}}$, we denote $L_{jk^{\prime}}=K_{j}\cdot
x_{jk^{\prime}}$, where $K_{j}$ is a constant for the fixed bin that can be
computed from Eq. 1. Suppose now the $k$-th liquidity provider place $x_{jk}$
on the bin $R_{j}$, similarly, we get that the liquidity contributed by the
token is $L_{jk}=K_{j}\cdot x_{jk}$.

According to the mining scheme, which distribute rewards proportional to the
liquidity contributed by liquidity providers. The $k$-th liquidity provider
can get

$R_{j}\cdot\dfrac{L_{jk}}{L_{jk^{\prime}}+L_{jk}}=R_{j}\cdot\dfrac{x_{jk}}{x_{jk}+x_{k^{\prime}}\cdot
R_{j}/R_{r}}.$

Obviously, the $k$-th liquidity provide should place all liquidity on the bins
$\mathcal{B}_{r}$, since there are no rewards on the other bins needing $X$.
Then the optimal strategy for the $k$-the liquidity provider forms the
following constrained optimization problem.

$\displaystyle\max\leavevmode\nobreak\ \leavevmode\nobreak\
\sum_{j\in\mathcal{I}_{r}}R_{j}\cdot\dfrac{x_{jk}}{x_{jk}+x_{k^{\prime}}\cdot
R_{j}/R_{r}}$ $\displaystyle s.t.\leavevmode\nobreak\ \leavevmode\nobreak\
\leavevmode\nobreak\ \sum_{j\in\mathcal{I}_{r}}x_{jk}=x_{k}$

The Lagrangian function for the above problem is:

$\mathcal{L}(x_{jk},\lambda)=\sum_{j\in\mathcal{I}_{r}}R_{j}\cdot\dfrac{x_{jk}}{x_{jk}+x_{k^{\prime}}\cdot
R_{j}/R_{r}}+\lambda\cdot(\sum_{j\in\mathcal{I}_{r}}x_{jk}-x_{k})$

The optimal solution is then given by the Karush–Kuhn–Tucker(KKT) conditions:

$\left\\{\begin{array}[]{ll}&\dfrac{\partial\mathcal{L}}{\partial
x_{jk}}=R_{j}\cdot\dfrac{x_{k^{\prime}}\cdot
R_{j}/R_{r}}{(x_{jk}+x_{k^{\prime}}\cdot
R_{j}/R_{r})^{2}}-\lambda=0,\leavevmode\nobreak\ \leavevmode\nobreak\
j\in\mathcal{I}_{r}\\\
&\dfrac{\partial\mathcal{L}}{\partial\lambda}=\sum_{j\in\mathcal{I}_{r}}x_{jk}-x_{k}=0\end{array}\right.$

Solving the equations we get the optimal strategy:

(2) $\left\\{\begin{array}[]{ll}&x_{jk}=x_{k}\cdot
R_{j}/R_{r},\leavevmode\nobreak\ \leavevmode\nobreak\ j\in\mathcal{I}_{r}\\\
&\lambda=\dfrac{R_{r}x_{k}}{(x_{k}+x_{k}^{\prime})^{2}}\end{array}\right.$

The optimal strategy Eq. 2 matches the proposed strategy, which means changing
strategy will not improve the revenue. Thus the strategy is a Nash
equilibrium. ∎

Note that the strategy in the above Nash equilibrium is not the dominant one,
i.e., not optimal in all cases. A counter-example is as follows:

###### Example 0.

Consider the following settings:

  * ${\circ}$

$\mathcal{B}=\\{B_{0},B_{1}\\}$ and the current price $p_{c}=p_{0}$, i.e., the
left boundary of the bin $B_{0}$.

  * ${\circ}$

The mining reward is equally distributed on $\mathcal{B}$, i.e.,
$R_{0}=R_{1}=1/2R$

  * ${\circ}$

There are $2$ liquidity providers and the $1$-th deploy all $X$ token into bin
$B_{0}$.

We check the optimal strategy for the $2$-th liquidity provider. If he uses
the Nash equilibrium strategy, he will deploy $x_{2}\cdot R_{0}/R$ and
$x_{2}\cdot R_{1}/R$ of $X$ into $B_{0}$ and $B_{1}$ respectively. In this
case, his revenue is $R_{0}+R_{1}\cdot\frac{x_{2}\cdot R_{1}/R}{x_{2}\cdot
R_{1}/R+x_{1}}$. Obviously, the strategy is not optimal, since nobody is
competing with him in bin $B_{0}$. He should place as small amount greater
than $0$ as he can to get the whole reward $R_{0}$ and place the left into bin
$B_{1}$ to take up a large proportion and the limitation revenue he will get
is $R_{0}+R_{1}\cdot\frac{x_{1}}{x_{1}+x_{2}}$.

Although the Nash equilibrium strategy is not optimal, or even not unique, we
can treat is as optimal in practice largely. The reason is that in practice
the liquidity providers appear one after another, and the decisions are made
in sequence. The reward provider can guide the liquidity providers to choose
that strategy if he acts as the first liquidity provider and places initial
liquidity using the Nash equilibrium strategy.

In the general case, where the current price $p_{c}$ is not on the boundary of
any bin and the bin $B_{j}$ contains $p_{c}$ is in the support of reward
distribution, i.e., $R_{j}>0$ . Things become complicated since when adding
liquidity in $B_{j}$, both $X$ and $Y$ tokens are needed and the requirements
satisfy a certain relation, as in Eq. 1. Thus a close-formed Nash equilibrium
strategy is hard to find. And for the $k$-th liquidity provider, the optimal
strategy is given by the following optimization problem:

(3) $\displaystyle\max\leavevmode\nobreak\ \leavevmode\nobreak$
$\displaystyle\sum_{i\in\mathcal{I}_{r}}R_{i}\cdot\dfrac{x_{ik}}{x_{ik}+X_{i}}+\sum_{i\in\mathcal{I}_{l}}R_{i}\cdot\dfrac{y_{ik}}{y_{ik}+Y_{i}}+R_{j}\cdot\dfrac{x_{j}k}{x_{j}k+X_{j}}$
$\displaystyle s.t.\leavevmode\nobreak\ \leavevmode\nobreak\
\leavevmode\nobreak$ $\displaystyle
x_{jk}+\sum_{i\in\mathcal{I}_{r}}x_{ik}=x_{k}$ $\displaystyle
y_{jk}+\sum_{j\in\mathcal{I}_{l}}y_{ik}=y_{k}$ $\displaystyle
y_{jk}=\dfrac{\sqrt{p_{c}}-\sqrt{p_{j}}}{1/\sqrt{p_{c}}-1/\sqrt{p_{j+1}}}\cdot
x_{jk},$

where $\mathcal{I}_{l}$ are the indicator set that contains the index of bins
left to $B_{j}$ and $\mathcal{I}_{r}$ is defined symmetrically; $X_{i}$
denotes the amount of $X$ token placed into bin $B_{i}$ and $Y_{i}$ the amount
of $Y$ token.

In general, the close-formed solution is also hard to find and We leave the
problem of solving the Prob. 3 for future work. Here we give some qualitative
analyses. For the liquidity providers, their decision procedure can be divided
into two stages. At the first stages, they determine how many $X$, and the
corresponding $Y$ token, are placed into the bin $B_{j}$; and then they
allocate the remaining $X$ and $Y$ tokens to $\mathcal{B}_{r}$ and
$\mathcal{B}_{l}$ respectively. Then the situation falls into the boundary
current price $p_{c}$ case, where the “optimal” strategy for the liquidity
providers is to put their liquidity proportional to the rewards distribution
following the same derivation process. When the reward for the liquidity in
bin $B_{j}$ does not account for a large proportion, i.e. $\frac{R_{j}}{R}\ll
1$, the liquidity providers can safely omit the influence made by it.

Till now we analyzed the liquidity provision strategy with the current price
$p_{c}$ is fixed. Here we also do some qualitative analyses considering the
influence of the price change, i.e. the stability from the liquidity
providers’ view. We suppose that the price $p_{c}$ changes to $p_{f}<p_{c}$,
and similar results for the other case can be obtained by the symmetry. Since
$p_{f}<p_{c}$, now a liquidity provider passively swaps some $Y$ to $X$ token.
The impact of the swapping procedure is local since it will only influence the
liquidity in the bins that has intersection with $[p_{f},p_{c}]$. Besides,
since the $Y$ token is swapped out in one way, the The proportional
distribution relationship is not changed, omitting the bin at the border. Thus
the liquidity provider does not need to modify his liquidity provision for
$Y$. As for the token $X$, we list several conditions that the liquidity
provider does not need to modify his provision to maintain an approximate
optimal position.

  * ${\circ}$

The rewards on the related bins, denote the index set as $I_{f}$, does not
account for a large proportion, i.e., $\frac{\sum_{i\in I_{f}R_{i}}}{R}\ll 1$.

  * ${\circ}$

The swapped $X$ token does not dominate the whole amount, making sure that
moving these tokens to the other bins will not have a significant impact.

Figure 2. Arbitrary reward distribution leads to approximated expected
liquidity distribution.

In conclusion, the approximately optimal strategy in practice for a liquidity
provider is to allocate his liquidity proportional to the reward distribution
and the strategy has a certain degree of stability.

###  4.2. The Reward Providers’ Perspective

(a) The low slippage distribution.

(b) The price stabilization distribution.

(c) The Uniswap V2 distribution.

Figure 3. Illustration of reward distribution designs with different goals and
the corresponding liquidity distribution.

We discuss how the reward provider can utilize the mining scheme to optimize
the liquidity distribution, with the assumption that all the liquidity
providers are purely rational and will take the approximate optimal strategy
in Section 4.1.

In this situation, the liquidity is distributed the same portion as the reward
on the chosen bins, except for the bin $B_{j}$ that the current price $p_{c}$
lies in. To simplify the discussion, we omit the difference between the bin
$B_{j}$ and the others and assume the liquidity on it is “proportional” as
well, focusing on the design of the reward distribution
$\\{R_{i}|i\in\mathcal{B}_{b}\\}$. The resulting liquidity distribution is
illustrated in Fig. 2.

We list three  typical designs for the reward distribution. Fig. 3 illustrates
the reward and the corresponding liquidity distribution. Below we discuss in
details.

  * ${\circ}$

Low slippage case: in this case, the reward provider aims to minimize the
slippage for swapping. In most cases, the more liquidity concentrates on the
bins around the current price $p_{c}$ lies in, the lower slippage we get. Thus
we set the rewards decrease with the distance to the current price $p_{c}$, as
shown in Fig. 3.(a). Note that the reward provider should not only give reward
to the bin $B_{j}$ that contains the current price $p_{c}$, since this is
unstable, i.e. when the price changes frequently in a relatively small range
that covering multiple bins, the reward provider need to adjust the bin
$\mathcal{B}=\\{B_{j}\\}$ frequently too.

  * ${\circ}$

Price stabilization case: in this case, the reward provider aims to keep the
price in the interval $[p_{a},p_{b}]$ as far as possible. To a certain extent,
given a fixed number of tokens, the distribution of liquidity should be
opposite to the low slippage case. Since the more liquidity concentrates on
the border, the more $X$ ($Y$) token needed for traders to break the price
boundary $p_{a}$ ($p_{b}$). Thus we set the rewards decrease with distance to
the border price $p_{a}$ and $p_{b}$, as shown in Fig. 3.(b).

  * ${\circ}$

The Uniswap V2 case: for those reward providers who prefer the liquidity
distribution in Uniswap V2, we show that the same distribution can be realized
through setting the rewards properly. Remember that Uniswap V2 use the formula
$x\cdot y=k$ to describe the supply and demand relationship between $X$ and
$Y$, which can be regarded as the limit case when setting $d\to\infty$.
Suppose the current price is $p_{c}$, the current liquidity for $X$ are
deployed in the range $[p_{c},\infty)$ and $Y$ in $(0,p_{c}]$. When the price
changes from $p_{0}$ to $p_{1}$ and $p_{c}<p_{0}<p_{1}$, a mount of $X$ tokens
are swapped into $Y$ passively for the liquidity providers. We have:

$|\Delta x|=x_{0}-x_{1}=\sqrt{k}\cdot(1/\sqrt{p_{0}}-1/\sqrt{p_{1}}).$

When the price changes from $p_{0}$ to $p_{1}$ and $p_{1}<p_{0}<p_{c}$, a
mount of $Y$ tokens are swapped into $X$ passively for the liquidity
providers. We have:

$|\Delta y|=y_{0}-y_{1}=\sqrt{k}\cdot(\sqrt{p_{0}}-\sqrt{p_{1}}).$

The above derivation shows that the liquidity is proportional to the change in
$\Delta 1/\sqrt{p}$ right to $p_{c}$ and proportional to the change in
$\Delta\sqrt{p}$ on the left. Thus the corresponding reward distribution is
shown in Fig. 3.(c). Note that to emphasize the relationship between price and
token amount, we use the dash line to mark the price axis.

In practice, a reward provider can choose any above-mentioned strategies
according to their own needs, or it can be a mixture of them.

##  5\. Conclusion & Discussion

In this paper, we propose a liquidity mining scheme for Uniswap V3, which
realizes the overall liquidity distribution through the fine control of the
rewards in local bins, taking flexibility, fairness and stability in to
consideration. We analyze the strategic response both for the liquidity
providers side and the reward provider side. For the liquidity providers, this
forms a multi-player zero-sum game. We analyze the Nash equilibrium for some
cases and use it to guide the strategy in general case. Roughly speaking, a
liquidity provider should deploy his liquidity proportional to the reward
distribution. Based on the response from liquidity providers, we propose and
analyze several realizations for the scheme which can be choose flexibly by
the reward provider to optimize the liquidity distribution.

There are some important problems we briefly discuss here and leave them for
future work. First, as mentioned at the beginning of Section 3, in practice
the strategy of a liquidity provider is determined both by the mining reward
policy and price trend forecasting, since the “active” bins, i.e. the price
often falls into, have more fee income. We need to determine how much this
will influence the final liquidity distribution.

The fine control of local rewards leads to more computation and space
complexity, where a naive implementation is $O(n)$, where $n=|\mathcal{B}|$.
This is not acceptable on the blockchain with high gas fee such as Ethereum.
Exploring the efficient implementation of the scheme, or a combination of
Layer-2 solution is of vital importance.

## References

  * (1)
  * Adams (2018) Hayden Adams. 2018\.  _Uniswap Whitepaper_.  https://hackmd.io/@HaydenAdams/HJ9jLsfTz
  * Adams et al. (2020) Hayden Adams, Noah Zinsmeister, and Dan Robinson. 2020\.  Uniswap v2 core.  _URl: https://uniswap.org/whitepaper. pdf_ (2020).
  * Compound (2021) Compound. 2021.  _About Governance Token COMP_.  https://compound.finance/docs/governance#comp (Accessed on 12/08/2021).
  * Goyal (2020) Shubham Goyal. 2020\.  _What is Compound’s Liquidity Mining (COMP)_.  https://www.delta.exchange/zh/blog/what-is-compound-liquidity-mining
  * Karaivanov (2021) Doncho Karaivanov. 2021\.  _How to Farm SUSHI on SushiSwap – The Simple Guide_.  https://chainbulletin.com/how-to-farm-sushi-on-sushiswap-step-by-step-guide/