bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 16쪽 중 13쪽
Age” Atom inserted
as the Predicate of the Triple:
{
"subject": "User A",
"predicate": "FirstName",
"object": "Bob"
}
{
63
"subject": "User A",
"predicate": "Age",
"object": "32"
}
By using the same Atoms and Triples to express “Name” and “Age,” both doctor’s offices ensure that their
data is structured in a consistent and interoperable manner. This consistency means that any platform
or application interacting with this data can easily understand and reconcile it, regardless of its point of
origination.
Optimal Data Flatness
While it is essential for data to be relatively ‘flat’ to facilitate ease of use and interoperability, overly flat
data structures can lead to significant ambiguities. This concept is illustrated by what can be referred to as
the “Father Father Problem”, a term coined by Mr. John McClure of Intuition.
Consider an Atom, which is the fundamental unit of information in this context, represented solely by the
string “father. ” Although this representation is maximally flat, it lacks the necessary context to discern its
intended meaning. The term “father” could refer to a parental figure or a priest in the Christian church.
Without additional context, the true meaning of this Atom remains unclear.
Ambiguity and Economic Incentives In an entirely flat data structure, where Atoms are maximally
minimized, additional context would added through Triples (contextual data points). For example, in the ‘Fa-
ther Father Problem’, a Triple could be created to add context, such as {[Father Atom] [has definition]
[parental father]} . However, in an entirely permissionless environment, this method does not guarantee
a consistent or deterministic definition. For instance, some users might use the Atom “father” to denote a
parental father, while others might still use it to refer to a priest. This inconsistency introduces extreme
ambiguity, making the data challenging to interpret accurately.
Moreover, such ambiguity can lead to unintended economic consequences. For example, if User A makes
a claim {[Bob] [is father of] [John]} intending to express a parental relationship, they would receive
shares of the Vault associated with the Atom [is father of]. If User B then makes a claim {[Joe] [is father
of] [Bill]] , intending to express a religious relationship, User A would still be rewarded economically
despite their data being entirely unrelated to User B’s claim. This misalignment contradicts the goal of
rewarding convergence and meaningful contributions.
Achieving Optimal Flatness To avoid these pitfalls, it is crucial to strike a balance in the flatness of
data. While Intuition allows users the flexibility to structure Atoms as they see fit, it highly recommends
the use of shallow-nested, generic schemas to define Atoms. This approach provides explicit clarity about
what an Atom represents, reducing ambiguity and enhancing data reliability.
A standard generic schema might look like this:
{
"genericSchema": {
"name": "string",
"description": "string",
"url": "string",
"image": "string"
}
}
By incorporating a few “loosely immutable” fields, we can ensure a degree of certainty that the Atom
accurately represents the intended concept, and that the core concept represented remains stable over time.
The Importance of Loosely Immutable Definitions
If an Atom’s definition were solely derived from social consensus and claims, it could change unpredictably,
leading to confusion and misrepresentation. For instance, if an Atom initially defined as “trustworthy” is
later redefined as “liar” based on social consensus, historical claims would be misleading without considering
the time context, complicating the system unnecessarily.
64
“Loosely immutable” definitions mitigate this issue by providing stability while allowing for updates. The
term “loosely” indicates that the definition can be changed, but such changes are deliberately challenging to
implement. This ensures that users can trust that the definitions will not shift unpredictably.
To allow for necessary updates over time, some potential methods include:
1. Use Triples to update the Atom’s definition.
2. Enable shareholders of an Atom to vote on updates to the Atom’s off-chain data, creating fractal
data DAOs for all concepts.
This balance ensures that while the definitions of Atoms can evolve, they do so in a controlled and deliberate
manner, preserving the integrity and utility of the data.
8.5.4 Signaling
The concept of signaling in Intuition is decoupled from Triples, enabling many-to-one attestations/claims.
This decoupling ensures that multiple participants can attest to the same statement without creating redun-
dant data.
Signaling Mechanism
1. Depositing T okens : Expression of Signal is achieved by depositing tokens into the Vault of
the Atom or Triple. This act of depositing tokens serves as a Signal of the user’s belief in the
Atom/Triple’s validity and/or relevance.
2. Positive and Negative Vaults : For Triples, participants have the option to deposit tokens into
either the Positive Vault to affirm a claim, or the Negative Vault to reject it. This dual-vault system
allows for a nuanced representation of consensus within the community.
3. Economic Interpretation : The state of balances within these Vaults reflects “who is saying what,
and with what degree of conviction. ” This model enables the system to interpret data based on the
number of participants supporting a claim, the economic bandwidth expended, and the reputation
of each participant.
Example Signal
To articulate a statement within the Intuition system, participants deposit tokens into a Vault associated
with a specific Triple. For example, if a participant wishes to assert that {[Bob] [is] [trustworthy]} ,
and this Triple already exists, they would express this sentiment by depositing tokens into the Positive Vault
of the existing Triple, rather than by creating a new Triple.
With this, each Vault can exist in an infinite number of states based on participant deposits. For instance,
a Vault could have 10 participants with a total value locked (TVL) of 10 ETH in the positive Vault, and
100 participants with a TVL of 5 ETH in the negative Vault. This state can be interpreted in many ways,
based on several variables, such as:
1. The number of depositors in each vault
2. The reputation of each depositor, especially in the given context.
3. The economic bandwidth expended, in total and by each depositor, to support each claim.
4. The duration of the value locked by each participant.
Intuition itself remains neutral and does not assert what is true or false. Instead, it facilitates the generation
of semantically interpretable states. Anyone can then build on this foundation to interpret the state in any
way.
Independence and Correlation In the proposed implementation of Intuition, a Triple’s Positive and
Negative Vaults are economically uncorrelated - that is, activity in a Triple’s Positive Vault will not impact
activity in the Triple’s Negative Vault. This is because, in a sense, these are two entirely separate claims.
However, the activity does indirectly benefit both sides because they reference the same Atoms. Since these
Atoms are utilized by participants in both the Positive and Negative Vaults, value is disseminated to both
sides at the Atom level.
65
8.5.5 Fees and Bonding Curves
In Intuition, bonding curves and fees play a pivotal role in determining the amount of assets a user can
redeem from a Vault after depositing. When a user deposits assets into a Vault, they are issued Shares in
return. These Shares represent the user’s stake and can be redeemed for assets at any time. The price of
these Shares may follow any bonding curve, though the intended behavior of the system is to reward current
depositors whenever additional economic bandwidth is allocated to the respective Vault.
To ensure this behavior regardless of the bonding curve leveraged, the system implements a concept known
as the Entry Fee ( entryFee). The entryFee is a portion of a deposit that is distributed to all current Vault
depositors. The system may also implement an optional Exit Fee exitFee on redemptions, providing a
portion of redemptions to all current Vault depositors.
EntryF ee Mechanism Entry F ee paid to all current shareholders to incentivize current holders
entryFee are exitFee are configurable parameters set by the protocol and can vary across different Vaults.
The purpose of the these fees is to incentivize different behaviors and create various economic dynamics
within the protocol. For instance, higher entryFees might discourage frequent trading, promoting longer-
term holding, while lower entryFees might encourage more frequent interactions. By customizing the
entryFee and exitFee for each Vault, the protocol can support a wide range of applications and user
behaviors.
To streamline the process and minimize gas costs, entryFees and exitFees can be distributed to current
Vault shareholders through an increase in Share price rather than direct payments. For example, when a
user deposits assets and an entryFee is applied, the entryFee can increase the total assets in the Vault
without increasing the total number of Shares. This mechanism effectively raises the share price, allowing
existing depositors to redeem their Shares for a greater number of assets. Thus, the value of the entryFee is
indirectly transferred to the current depositors.
Example Bonding Curves While entryFees and exitFees can encourage behavior to some extent, to
accommodate the diversity of potential applications, it is recommended that a Bonding Curve Registry be
implemented. This registry allows Vault creators to choose from a variety of predefined bonding curves when
setting up a new Vault. The selected bonding curve will dictate the sharePrice curve of each Vault, and,
consequently, the dynamics of share issuance and redemption for that Vault. To illustrate different scenarios
benefiting from different bonding curves, we will explore some example curves:
Flat / Pro-Rata
In a Flat / Pro-Rate bonding curve, share price remains constant, minus any share price changes incurred
through fees. This may be useful in an environment that benefits from the maximization of entities partici-
pating and amount deposited. Above is an example graph of a flat curve represented by the equation:
y = 5 ∗ y
66
The graph depicts a horizontal line, signifying that the value of y remains constant regardless of variations
in x. In this context, an individual can consistently redeem the same amount of assets that they initially
deposited into the Vault, less any applicable fees.
Linear
In a linear bonding curve, share price linearly increases. This may be useful in scenarios in which additional
signal has diminishing returns, or scenarios in which early signal is more heavily weighted. Provided above
is an example graph of a linear curve represented by the equation:
y = 2 ∗ x + 3
y. In this context, as the share price increases or decreases along the curve, depositors would be able to
redeem more or fewer assets from the vault depending on the current position on the line relative to their
deposit points.
Exponential
In an exponential bonding curve, share price increases exponentially. This may be useful in the construction
of speculative games, providing participants with the potential to generate significant returns. Above is an
example graph of an exponential curve represented by the equation:
y = ex/2
Sigmoid
Sigmoid curves can provide an interesting environment that encourages participation within a discrete range.
This may be useful for a number of purposes, such as when a predetermined amount of collateral is deemed
necessary to establish trustworthiness or validity of a claim. Above is a sigmoid curve represented by the
equation:
67
y = 1/1 + e−x
A Singular Intuition System
The capability to support arbitrary bonding curves within the Intuition system is essential in preventing
fragmentation. If the system were restricted to a single bonding curve, it would inevitably fail to optimize
across all use cases. Such limitations would lead to the emergence of multiple, disparate deployments of
Intuition, resulting in fragmented data and liquidity—outcomes antithetical to the system’s foundational
goals.
By allowing developers to customize bonding curves to suit specific requirements, Intuition provides the
flexibility necessary to accommodate diverse applications. This adaptability ensures that various use cases
can be effectively addressed within a unified framework. Consequently, developers are empowered to design
tailored economic models and interactions, thereby enabling the construction of a wide array of applications
on top of a singular, cohesive implementation of the Intuition system. This approach preserves the integrity
and cohesiveness of the data ecosystem.
Example F ee & Bonding Curve Implementation V alue Flows To illustrate the intended behavior,
we will examine the value flows within an example implementation utilizing a ‘pro-rata’ bonding curve for all
Vaults. In this model, the Share Price changes solely due to entry and exit fees paid to each vault, ensuring
that users cannot lose more than their initial deposit, minus the fees. We will also assume that the initial
share price for each Vault is set at 1 (i.e., 1 Asset = 1 Share). All values will be denominated in ETH.
Atom Creation V alue Flows Static Atom Cost
Let CatomCreation represent the total amount of static fees for creating an Atom, atomCost.
• protocolCreationFee: A fixed fee paid to the protocol’s multi-signature wallet address.,
FprotocolCreate
• walletInitialDeposit: A fixed amount deposited on the Atom Vault on behalf of the Atom Wallet,
FatomW allet
• minShare: A minimal number of shares purchased for a neutral address to prevent share price
inflation attacks, referred as ‘ghost shares’, Fghost
The total atomCost Ac may be represented as:
CatomCreation = FprotocolCreate + FatomW allet + Fghost
Deposit F ees
If msg.value exceeds atomCost, the remainder is deposited on the Atom Vault on behalf of the msg.sender,
and incurs a depositFee, FprotocolDeposit , paid to the protocol.
• protocolFeeRate: The percentage fee applied to the user deposit, to be paid to the protocol,
FprotocolF eeP ercent
68
• userDeposit: The total amount of assets sent by the user during the create transaction, AuserDeposit
The additional deposit fee FprotocolDeposit is calculated as:
FprotocolDeposit = (Auser − CatomCreation ) ∗ FprotocolF eeP ercent)
Summary of State After Creation
• userShares: Let Suser represent the amount of Shares received by the User in the Atom’s Vault:
– Suser = AuserDeposit − CatomCreation − FprotocolDeposit
• userAssets: Let Auser represent the amount of Assets that can be redeemed from the Vault by the
User:
– Auser = Suser, as no entryFee is charged during the creation deposit flow; thus, sharePrice
remains 1:1.
• totalVaultAssets = AvaultT otal = Auser + FatomW allet + Fghost
• totalVaultShares = SvaultT otal = Auser + FatomW allet + Fghost
Given that assets will equal shares, the additional allocations are as follows:
• Shares to the Atom wallet address = FatomW allet
• Shares to the 0x0 address (lost) = Fghost
69
• Assets to the Protocol = FprotocolCreate + FprotocolDeposit
Deposit Atom:
Initial Summary of State
• totalVaultAssetsBefore: The total Assets in the Vault before the state change introduced by the
deposit transaction, AvaultT otalBef ore
• totalVaultSharesBefore: The total outstanding Shares of the Vault before the state change intro-
duced by the deposit transaction, SvaultT otalBef ore
• sharePriceBefore: The amount of Assets (ETH) each share can be redeemed for at the beginning
of the transaction, SpriceBef ore
– SpriceBef ore = AvaultT otalBef ore/SvaultT otalBef ore
Deposit F ees
Let FatomDeposit represent the total fees paid for depositing on an Atom:
• msg.value: The value passed through to the depositAtom function, AuserDeposit
• protocolFeeRate: The percentage fee applied to the user deposit, to be paid to the Protocol
FprotocolF eeP ercent
• protocolFee: The fee paid to the protocol, Fprotocol
– Fprotocol = AuserDeposit ∗ FprotocolF eeP ercent
• entryFeePercent: The percentage fee applied to the user deposit, that will be paid to the current
Vault depositors, FentryF eeP ercent
• entryFee: The fee paid to current depositors in the Atom Vault, Fentry
– Fentry = (AuserDeposit − Fprotocol) ∗ FentryF eeP ercent
70
The total Atom Deposit Fee, FatomDeposit may be represented as:
FatomDeposit = Fprotocol + Fentry
Summary of State After Deposit
• userShares: The amount of Shares received by the User in the Atom’s Vault, Suser
– Suser = (AuserDeposit − FatomDeposit)/SpriceBef ore
• userAssets: The amount of the Vault’s Assets (ETH) that Suser can be redeemed for, Auser:
– Auser = AuserDeposit − FatomDeposit
• totalVaultAssetsAfter: The total Assets of the Vault after the state change introduced by the
deposit transaction, AvaultT otalAf ter:
– AvaultT otalAf ter = AvaultT otalBef ore + AuserDeposit − Fprotocol
• totalVaultSharesAfter: The total outstanding Shares of the Vault after the state change intro-
duced by the deposit transaction, SvaultT otalAf ter:
– SvaultT otalAf ter = SvaultT otalBef ore + Suser
• sharePriceAfter: The amount of Assets (ETH) each share can be redeemed for after the transac-
tion, SpriceBef ore
– SpriceAf ter = AvaultT otalAf ter/SvaultT otalAf ter
With this, the entryFee will result in an increase in sharePrice, as totalVaultAssets, the numerator, will
increase more than totalVaultShares, the denominator. This allows all current depositors to redeem their
Shares from the Vault for an increased sharePrice, effectively achieving a distribution of entryFees paid
to all current shareholders.
Redeem Atom
Initial Summary of State
• totalVaultAssetsBefore: The total Assets in the Vault before the state change introduced by the
deposit transaction, AvaultT otalBef ore
• totalVaultSharesBefore: The total outstanding Shares of the Vault before the state change intro-
duced by the deposit transaction, SvaultT otalBef ore
• sharePriceBefore: The amount of Assets (ETH) each share can be redeemed for at the beginning
of the transaction, SpriceBef ore
– SpriceBef ore = AvaultT otalBef ore/SvaultT otalBef ore
Redemption F ees
Let FatomRedeem represent the total fees paid for redeeming Shares of an Atom Vault:
• redeemAmount: The amount of Shares to be redeemed, SuserRedeem
• protocolFeeRate: The percentage fee applied to the user redemption, to be paid to the Protocol
FprotocolF eeP ercent
• protocolFee: The fee paid to the protocol, Fprotocol
– Fprotocol = SuserRedeem ∗ SpriceBef ore ∗ FprotocolF eeP ercent
• exitFeePercent: The percentage fee applied to the user redemption, that will be paid to the current
Vault depositors, FexitF eeP ercent
• exitFee: The fee paid to current depositors in the Atom Vault, Fexit
– Fexit = ((SuserRedeem ∗ SpriceBef ore) − Fprotocol) ∗ FexitF eeP ercent
The total Atom Redemption Fee, FatomRedeem may be represented as:
FatomRedeem = Fprotocol + Fexit
Summary of State After Creation
71
• userShares: The amount of Shares owned by the User in the Atom’s Vault, Suser
– Suser = SuserBef ore − SuserRedeem
• userAssets: The amount of the Vault’s Assets (ETH) received by the user, Auser:
– Auser = (SuserRedeem ∗ SpriceBef ore) − FatomRedeem
• totalVaultAssetsAfter: The total Assets of the Vault after the state change introduced by the
redemption transaction, AvaultT otalAf ter:
– AvaultT otalAf ter = AvaultT otalBef ore − Auser − Fprotocol
• totalVaultSharesAfter: The total outstanding Shares of the Vault after the state change intro-
duced by the redemption transaction, SvaultT otalAf ter:
– SvaultT otalAf ter = SvaultT otalBef ore − Suser
• sharePriceAfter: The amount of Assets (ETH) each share can be redeemed for after the transac-
tion, SpriceBef ore
– SpriceAf ter = AvaultT otalAf ter/SvaultT otalAf ter
With this, the exitFee will once again result in an increase in sha프로젝트로 돌아가기
