bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 16쪽 중 14쪽
rePrice, as totalVaultAssets, the
numerator, will decrease less than totalVaultShares, the denominator. This allows all current depositors
72
to redeem their Shares from the Vault for an increased sharePrice, effectively achieving a distribution of
exitFees paid to all current shareholders.
Triple Creation Fees
Static T riple Cost
Let CT ripleCreation represent the total amount of static fees for creating an Triple, tripleCost.
• protocolCreationFee: A fixed fee paid to the protocol’s multi-signature wallet address,
FprotocolCreate
• atomFeeOnTripleCreation: A fixed fee paid to the underlying Atom vaults,
FatomF eeOnT ripleCreation
• minShare: A minimal number of shares purchased for a neutral address to prevent share price
inflation attacks, referred as ‘ghost shares’, Fghost. Since each triple has 2 associated Vaults, this
amount during Triple creation is 2 ∗ Fghost.
The total tripleCost CtripleCreation may be represented as:
CtripleCreation = FprotocolCreate + FatomF eeOnT ripleCreation + (2 ∗ Fghost)
73
Deposit F ees
If msg.value exceeds tripleCost, the remainder is deposited on the Triple’s Positive Vault on behalf
of the msg.sender. This process incurs an additional deposit fees paid to the Protocol, FprotocolDeposit .
• protocolFeeRate: The percentage fee applied to the user deposit, FprotocolF eeP ercent
• userDeposit: The total amount of assets sent by the user during the create transaction., AuserDeposit
The additional deposit fee FprotocolDeposit is calculated as:
FprotocolDeposit = (AuserDeposit − CT ripleCreation ) ∗ FprotocolF eeP ercent)
As per the default Triple deposit flow, outlined in the subsequent section, a portion of this deposit
amount is also deposited into each of the Triple’s underlying Atoms, atomDepositFraction. Let
atomDepositFraction be represented by FtripleAtomDeposit .
FtripleAtomDeposit = (( Auser − CtripleCreation ) − FprotocolDeposit ) ∗ FtripleAtomDepositP ercent, where
FtripleAtomDepositP ercent is the percent of the deposit routed to the Atom Vaults.
Summary of State After Creation
T riple State
• userTripleShares: The amount of Shares received by the User in the Triple’s Positive Vault,
SuserT riple
– SuserT riple = AuserDeposit − CtripleCreation − FprotocolDeposit
• userTripleAssets: The amount of Assets that can be redeemed from the Triple’s Positive Vault
by the User, AuserT riple
– AuserT riple = SuserT riple, as no entryFee is charged during the creation deposit flow; thus,
sharePrice remains 1:1.
• totalVaultAssets = AvaultT otal = AuserT riple + Fghost
• totalVaultShares = SvaultT otal = AuserT riple + Fghost
Atom State
• userAtomShares: Let Suser represent the amount of Shares received by the User in each respective
Atom Vault:
– Suser = ( FtripleAtomDeposit /3)/SpriceBef ore) − ((FtripleAtomDeposit /3)/SpriceBef ore) ∗ Fentry),
where SpriceBef ore is the sharePrice of each respective Atom Vault, and Fentry is the entryFee
of each Atom Vault.
• userAtomAssets: Let Auser represent the amount of Assets that can be redeemed from each respec-
tive Atom Vault by the User:
– Auser = Suser * SpriceAf ter, where SpriceAf ter is the Share Price of each Atom Vault after the
transaction. This can be calculated in the same way as in the ‘Atom Deposit’ section above, as
this is a normal Atom Deposit event.
Protocol State
• Assets to the Protocol = FprotocolCreate + FprotocolDeposit
Deposit T riple
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
74
– SpriceBef ore = AvaultT otalBef ore/SvaultT otalBef ore
Deposit F ees
Let FT ripleDeposit represent the total fees paid for depositing on an Triple:
• msg.value: The value passed through to the depositTriple 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
• atomDepositFraction: The amount of value that will be routed through the Atom Deposit flow for
each of the Triple’s respective Atom Vaults, FtripleAtomDeposit
– FtripleAtomDeposit = (AuserDeposit − Fprotocol) ∗ FtripleAtomDepositP ercent
• entryFee: The fee paid to current depositors in the Triple Vault, Fentry
– Fentry = (AuserDeposit − FtripleAtomDeposit − Fprotocol) ∗ FentryF eeP ercent
The total Triple Deposit Fee, FatomDeposit may be represented as:
FatomDeposit = Fprotocol + Fentry
T riple State
75
• userTripleShares: The amount of Shares received by the User in the Triple’s Vault, Suser
– Suser = (AuserDeposit − FatomDeposit − FtripleAtomDeposit )/SpriceBef ore
• userTripleAssets: The amount of the Vault’s Assets (ETH) that Suser can be redeemed for, Auser:
– Auser = AuserDeposit − FatomDeposit − FtripleAtomDeposit
• 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
Atom State
• userAtomShares: Let Suser represent the amount of Shares received by the User in each respective
Atom Vault:
– Suser = ( FtripleAtomDeposit /3)/SpriceBef ore) − ((FtripleAtomDeposit /3)/SpriceBef ore) ∗ Fentry),
where SpriceBef ore is the sharePrice of each respective Atom Vault, and Fentry is the entryFee
of each Atom Vault.
• userAtomAssets: Let Auser represent the amount of Assets that can be redeemed from each respec-
tive Atom Vault by the User:
– Auser = Suser * SpriceAf ter, where SpriceAf ter is the Share Price of each Atom Vault after the
transaction. This can be calculated in the same way as in the ‘Atom Deposit’ section above, as
this is a normal Atom Deposit event.
Redeem T riple
The mechanics of the “Redeem Triple” function operate in exactly the same manner as the “Redeem Atom”
function. When a user redeems from a Triple Vault, they are not required to redeem shares of the underlying
Atoms that constitute the Triple. This contrasts with the “Deposit Triple” event, where the user must
deposit into each respective Atom, introducing a variance between the mechanics of Triple Deposits and
Atom Deposits.
8.5.6 State Interpretation
Having examined the composition of the Intuition state and understood the multi-dimensional graph it gener-
ates, we can now explore methods for interpreting this state. The Intuition protocol is designed to maintain
a fundamentally neutral stance on the interpretation of its state, refraining from expressing any opinions on
what is true or false, or right or wrong. This neutrality allows for a broad spectrum of interpretations to be
built upon the foundational data. The aim is to decouple not only identities and data from the application
layer but also the algorithms that process and interpret this data. By providing a neutral base, Intuition
empowers users and developers to create their own lenses for viewing and understanding the data.
With this unbiased foundation, anyone can permissionlessly create arbitrary interpretations on top of the
Intuition protocol. This capability is essential for fostering an ecosystem where diverse algorithms and
interpretations can filter, weight, and distill data in various ways. Users can select the interpretations and
algorithms that best meet their specific needs, promoting a dynamic and customizable data experience. This
flexibility ensures that the system can adapt to a wide range of use cases and perspectives.
This approach addresses a significant issue with many current platforms, where users are confined to a
single, often biased, interpretation of data. For instance, platforms like Twitter enforce a single algorithmic
perspective, limiting users’ ability to see data through different lenses. Intuition’s strategy of decoupling
algorithms from the platform mitigates this issue, enabling users to toggle between various algorithms and
perspectives. This flexibility is crucial for fostering a richer, more inclusive understanding of data, where
multiple viewpoints can coexist and be explored.
76
Classifications of Interpretation
As previously outlined, interpretation can generally be categorized into three types: literal interpretations,
algorithms, and reality tunnels. Given Intuition’s unopinionated stance, it does not dictate how data should
be sorted or filtered. Nonetheless, these aspects are critical and must be developed. Therefore, Intuition
can provide the guardrails and incentives for the contribution of new interpretations, algorithms, and reality
tunnels.
Atoms and Triples can be utilized for this purpose, as anything can be represented as an Atom or Triple.
With Intuition, TCRs (Token Curated Registries) of interpretations, algorithms, and reality tunnels can be
curated, allowing developers and users to easily discover those that might be most suitable for their specific
context or use case.
Literal Interpretations
Consider what an Interpretation Registry for the Intuition state might look like when implemented on
Intuition. Suppose Organization X uses a ‘literal interpretation’ to enable a ‘follow’ functionality in their
application, expressed as {[I] [am following] [User]} , where the Subject [I] and the Predicate [am
following] remain constant across all Triples, with only the Object changing based on the user being
77
followed. Additionally, assume that Organization X interprets users with a positive balance in the Positive
Vault of the respective Triple as followers of the Object.
While this interpretation serves the purposes of Organization X, they might opt to create another
Triple referencing this structure, designating it as a literal interpretation. For example, this could
be represented as {[Organization X Official Interpretation List] [itemListElement] {[I] [am
following] [Object]}} . Utilizing this standardized Triple structure, Organization X could efficiently
develop a dashboard displaying all Objects of Triples staked on by Organization X, with the Subject
[Organization X Official Interpretation List] and Predicate [itemListElement]. This would gen-
erate a comprehensive list of all officially recognized interpretations by Organization X.
Organization X is incentivized to establish and make their Interpretation discoverable because adoption by
others could result in economic rewards through fee revenue. It is presumed that Organization X would hold
equity in this data structure, accrued through their usage and adoption of the data structure in question.
To further enhance the utility of this data, Organization X could create additional Triples, such as:
• {[Organization X Official Interpretation List] [itemListElement] {[I] [am
following] [Object]}} , which could be used to populate an official Intuition Interpretation
Registry of Registries
• {[I] [am following] [Object]} [hasType] [Follow Interpretation]} , which could be used
to populate a list of all Follow Interpretations
Algorithms and Reality T unnels
The principles applied to literal interpretations can similarly be extended to algorithms and reality tunnels
within the Intuition ecosystem. By decoupling the algorithms from the platform, users can create, share,
and adopt various algorithmic interpretations to suit their specific needs. This flexibility ensures that users
are not restricted to a singular, potentially biased viewpoint but can explore data through multiple, diverse
lenses.
For example, consider an algorithm designed by Organization Y to rank content based on user engagement
metrics. This algorithm could be represented as a Triple:
{[Organization Y Algorithm] [ranks] [Content]}
Users who prefer content ranked by engagement can adopt this algorithm, thereby tailoring their data
experience to their preferences. Organization Y can further enhance this by registering their algorithm in
the Intuition registry, making it discoverable and accessible to a broader audience. The same structure applies
to reality tunnels, which are more comprehensive frameworks that shape users’ overall data experiences. A
reality tunnel could include a combination of algorithms and interpretations, offering a unique perspective
on the data.
Key V ariables in State Interpretation In developing literal interpretations, algorithms, and reality
tunnels, numerous data aspects are crucial when interpreting the state of the Intuition system. Below is a
list of some criteria that may be valuable for developing data filtering techniques:
1. Amount of V alue Deposited on Each Atom
2. Amount of V alue Deposited on Triples Referencing Each Atom
3. Amount of V alue Deposited by the Atom into the System
4. Self-Claims (Atoms self-attesting to something)
5. T emporal Dynamics, such as the duration and recency of actions taken.
6. Contextual Reputation of Atoms
7. Endorsement Dynamics, such as mutual endorsements, endorsements within cliques, etc.
8. Contribution Quality , such as the truthfulness of historical claims made by an Atom
9. Interaction F requency
10. Cross-Platform Reputation, involving reputation of an entity represented by an Atom across
platforms.
11. Economic Behavior, which may influence the Signal an Atom generates.
78
12. Sentiment Analysis, such as whether or not an Atom is generally positive or negative in its
expression.
This limited subset of variables illustrates the inherent complexity and multidimensionality of the Intuition
system. It is impractical to assign a single ‘score’ to entities or to definitively determine what is true or
false, right or wrong. Instead, trust should be considered relative and context-dependent, based on the
observer’s perspective, similar to how trust is established in natural human interactions. This approach can
be facilitated by ‘lenses’ that filter data, which can be permissionlessly developed and equipped but should
never be locked into a singular mode of imposed groupthink.
Example Algorithm: Confidence Score Based on Stake Over Time
To demonstrate an example rudimentary Intuition-specifc algorithm, consider a confidence score based on
stake over time. Positive Stake over time would result in a Positive Weight, while Negative Stake over time
would result in a Negative Weight. The difference between these two weights could be used to calculate a
single ‘Weight’, though this would merely be a metric that parties could observe to better understand the
underlying record of activities.
Let P be the amount of positive stake and N be the amount of negative stake. The variance C between
positive and negative stakes at any given point in time is defined as:
C = P − N
For a given interval of time, the total variance Wc is the sum of all C values within that interval:
Wc = ∑ni=1 Ci = ∑ni=1(Pi − Ni)
Where i can represent the block number or any other discrete time interval.
This example illustrates the potential that exists at the higher levels of the technological stack. While the
Intuition protocol itself does not compute, enforce, or depend on these types of interpretations, it allows for
anyone to permissionlessly analyze its state to extract meaningful insights or to develop additional codified
logic. In this context, the temporal dimension of this basic algorithm is particularly noteworthy. Locking up
economic bandwidth for extended periods can serve as a robust indicator of a user’s confidence or belief in
a particular entity. This characteristic could be leveraged for various incentivization schemes. For instance,
envision a protocol that rewards users based on their sustained positive sentiment towards the protocol over
time.
Example Algorithm: EigenT rust
To explore a slightly more complex model, let us consider the EigenTrust Algorithm. The EigenTrust
algorithm is a reputation management system that uses a global trust value for each participant in a peer-
to-peer network. It works by assigning each peer a trust score based on their history of interactions. The
algorithm iteratively computes these trust values based on local trust scores and propagates them through
the network.
Here is the basic formula and steps involved:
1. Local T rust Calculation : Each peer i computes a local trust value cij for each other peer j they
have interacted with. This is based on the number of satisfactory interactions sij minus the number
of unsatisfactory interactions dij
cij = sij − dij/ ∑k(sik − dik)
2. Normalization: The local trust values are normalized to ensure they sum to 1 for each peer i:∑
j cij = 1
3. Global T rust Calculation : The global trust value tj for each peer j is computed by iteratively
aggregating the local trust values. Starting with an initial trust vector t0, typically with equal trust
for all peers, the trust vector is updated iteratively:
tk+1 = C T tk
Here, C is the matrix of normalized local trust values, tk is the trust vector at iteration k, and tk+1
is the trust vector at iteration k + 1. The iterations continue until t converges, i.e., changes between
iterations are below a certain threshold.
4. Convergence: The algorithm converges to the stationary distribution of the trust values, repre-
senting the global trust scores of the peers.
79
With this, we have just two of infinite possible interpretations of the state of the Intuition system. With
the development of new interpretations comes the unlocking of new potential use cases. As users and
developers create various algorithms and reality tunnels, the versatility and applicability of the Intuition
protocol expand, leading to a multitude of innovative applications.
9 Use Cases, Examples, & Implications
9.1 Web3 Use Cases & Examples
9.1.1 Transaction Security & W eb3 Navigability
The current landscape of Web3 interactions through wallets like MetaMask often presents users with a
complex and opaque interface. When interacting with smart contracts or sending transactions, users typically
see non-human-readable data strings, transaction hashes, and cryptic addresses, offering little context or
insight into the nature and safety of their actions. This lack of clarity can lead to uncertainty and even
security risks, as users are unable to easily assess the trustworthiness of the entities they are interacting
with.
With Intuition data integrated into wallets like MetaMask, users can see comprehensive and meaningful
information about the contracts and addresses they interact with. For instance, when a user is about to
engage with a smart contract, the wallet can display data about who has audited the contract and their
corresponding reputation scores. This may help provide trust around contract security and the fact that the
contract being interacted with is the correct contract.
Integrating Intuition data into Web3 wallets also addresses the critical issue of scams and fraudulent activities.
Users can see if a particular address has been flagged as a scammer by the community, based on collective
attestations. For example, if numerous users have reported a specific address as a phishing scam, this warning
can be prominently displayed within the wallet interface, alerting the user to proceed with caution or avoid
the interaction altogether.
The open and permissionless nature of Intuition’s data lake ensures that this information is continuously
updated and v프로젝트로 돌아가기
