rasmukyAbout rasmuky
Who am I?Just for some context:Young gen x or old millennial, depending on the sourceHusband to an amazing wife and father to two wonderful sonsLived in the United States my entire life. I’ve traveled an above average amount, but it’s safe to assume I’m a relatively stereotypical American…I generally feel more at home as a system 2 thinker, so don’t be alarmed if posts are longer than averageRelatively early adopter, but try to catch technology transitions once the UX is only mildly abrasive ...
rasmukyThis Web3 Life | The Set-up
TL;DR:I find writing is great way to reflect on the world around me and to think critically about my experiences. This Web3 Life is my space to do that for MEWeb3 is for creators and builders. I’m not an artist, and not currently a developer, so I’ll give writing a shotI think common / average Web3 community members need to share their experiences to help spotlight all user storiesThis is important to make sure everyone is represented as the space evolvesRepresentation of the affluent, wealth...
rasmukyThis Web3 Life | Ask not what you can do for your bank
TL;DR:In this post I’ll introduce the features and services that I value from a retail bank and explore compare and contrast my perception of legacy TradFi solutions and technology relative to the promise of Web3.TradFi financial institutions do provide valuable products and services to retail customers, relative to a totally bankless (e.g., pre 1900) constructRetail TradFi value proposition peaked decades ago and has been primarily value extractive (minimal innovation and non existent yield ...
A work in progress
rasmukyAbout rasmuky
Who am I?Just for some context:Young gen x or old millennial, depending on the sourceHusband to an amazing wife and father to two wonderful sonsLived in the United States my entire life. I’ve traveled an above average amount, but it’s safe to assume I’m a relatively stereotypical American…I generally feel more at home as a system 2 thinker, so don’t be alarmed if posts are longer than averageRelatively early adopter, but try to catch technology transitions once the UX is only mildly abrasive ...
rasmukyThis Web3 Life | The Set-up
TL;DR:I find writing is great way to reflect on the world around me and to think critically about my experiences. This Web3 Life is my space to do that for MEWeb3 is for creators and builders. I’m not an artist, and not currently a developer, so I’ll give writing a shotI think common / average Web3 community members need to share their experiences to help spotlight all user storiesThis is important to make sure everyone is represented as the space evolvesRepresentation of the affluent, wealth...
rasmukyThis Web3 Life | Ask not what you can do for your bank
TL;DR:In this post I’ll introduce the features and services that I value from a retail bank and explore compare and contrast my perception of legacy TradFi solutions and technology relative to the promise of Web3.TradFi financial institutions do provide valuable products and services to retail customers, relative to a totally bankless (e.g., pre 1900) constructRetail TradFi value proposition peaked decades ago and has been primarily value extractive (minimal innovation and non existent yield ...
Share Dialog
Share Dialog
A work in progress
Subscribe to rasmuky
Subscribe to rasmuky
I’ve now been immersed in Web3 for about eight months and have learned a lot about many of the fundamental technologies, frameworks, protocols and theories of the space. Throughout this time I’ve explored a number of use cases in my mind and considered how some may interconnect to strengthen network effects and general value propositions of individual protocols.
This post is my attempt to organize these thoughts into a Frankenstein’s monster apparatus and chart the path to research the technological, psychological, and economical challenges to creation of such an apparatus.
The foundational attributes of the monster which I’m most excited about are:
I think creation of a user self reported and managed “economic profile” is important to a healthy and optimized financial system on chain. Building credibility over time with responsible behavior enables users and protocols to interact more fluidly and efficiently while remaining permissionless, trustless, and undercollateralized (or most importantly not overcollateralized)
An economic profile does not have to equal identity…even anons can build financial credibility and creditworthiness simply by behaving responsibly
A dApp which enables robust programming of future money inflows and money outflows between and among various end use parties (i.e., with no intermediaries) would be new economic information not currently captured in the off-chain CeFi or TradFi environment. This could scale on-chain and be a valuable input to credit extension and the flow of commerce
A network of dApps which benefit from visibility into an economic profile can leverage features / data from one another and pay rewards in a common utility token. It’s possible that value accrual to a common utility token alone would incentivize a broad range of dApps to participate, or dApp to dApp payments for data could be an option as well
For dApps with common utility token, individual protocol governance could be driven by dApp use instead of basic hodling of an individual dApp’s utility / governance tokens. This drives influence to the users of the respective protocol instead of the hodlers of capital
Larger dApps within the common utility token apparatus will likely hold more of the primary utility token within an individual dApp treasury to facilitate periodic rewards funding, thus increasing governance influence over the common utility token for the larger dApps in the apparatus
The mosaic idea within this post is essentially unresearched at this point.
This apparatus is simply thoughts from my head now on digital paper. My commitment as a next steps is to do the research on technological feasibility, existing protocols in development, psychological / economical / political traps, and general evaluation of the major concepts to assess if there is something more to explore and build.
Any thoughts, feedback, critiques, memes you may have are welcomed in the replies to the companion TWEET to this post. #Learning.
I don’t know why, but when I let my mind wander I tend to dream up complex interconnected systems. I know, I have a problem…but it’s a thing I do.
So, I dreamt up this monster I call the Apparatus:
I think of it as a first draft which combines (i) my interpretation of some Web3 ecosystem fundamentals and (ii) what I initially want from the technology (which is also what I personally think will help to drive broad adoption).
Some context:
All of the protocols / dApps in the image above are introduced / explained below. I thought it might be helpful to the reader to get a basic visual of the full apparatus for reference
The image above displays a single chain architecture (e.g., what you would see on Optimism L2)
Expectation is the apparatus would be made composable or adoptable across all chains to provide a chain agnostic view of a Trsry parent account economic profile
Added benefit of chain agnostic composability is ability to bridge cross chain through protocol / smart contract layer Trsry treasury via “bridge” liquidity partner loans
Is the safest way to bridge between chains to not bridge at all?
This is not a comprehensive list of the pros and cons, but highlights a few topics which seem most radical relative to current ecosystem user expectations and / or critical to usefulness of the apparatus:
Anons, retail users, and enterprise users will agree to link wallets or account numbers to create an economic profile and will receive rewards for utilizing dApps and credit availability benefits in return for participation
Institutional and retail users will embrace self custody accounts, account substructures, single signor and multi signor key application and key management best practices to optimize security
Or, at least be open to an alternative to custody solutions between self custody and centralized custody. It seems current conventional wisdom doesn’t leave much room for an alternative framework to self custody or centralized custody
Enough activity can move and remain on chain to make settlement effective, efficient, and economical.
No need for a separate payroll direct deposit option if employers are settling all types of payments on chain
No need for cheap fiat on-ramps and off-ramps if a lot of end use settlement can occur natively on chain
Protocols will see enough value in leveraging parent account match tables and programmed transaction information to adopt a common token for rewards
It is technologically possible to store on chain (or via a private chain or zero knowledge chain) various new states or parent account attributes which can be called / evaluated in real time (efficiently) to enable decision making
If a responsibility or credit score is maintained, where is the state of the parent economic profile stored? How is state transition processed? How do other apps call the state or recent trend in the state? etc.
Similar questions for how to store, maintain history, process state change, and call on for other dApp use other information (e.g., programmed future payments)
A common rewards token treasury can be used across all chains as a secure alternative to bridging
Productive coordination with various governmental institutions is achievable in order to (i) support investigation of bad actors and (ii) facilitate private, human rights enabling, transactions from good actors
The outline below introduces a number of theoretical protocols / organizations which can generally operate independently. There could even be multiple competing versions of the individual topical organizations. However, all protocols (with the exception of Confidntl) foundationally leverage as key information (i) the economic profile enabled by Trsry and (ii) programmed money inflows and money outflows enabled by Prgrmd.
Protocol enables wallet address / account number aggregation to an economic profile (referred to as “parent”). Child accounts sign access control to parent account similar to a blind signing concept. Parent accounts can rescind access control or “revoke cash” to a child if requested and approved. A child account can only have one parent, but parent accounts can have multiple children. A parent account with children can be a child account to an ultimate parent (i.e., a sub-DAO “parent” account can have child accounts and an actionable economic profile at that sub-DAO level, but said account can also be a child to the top DAO parent account).
Protocol enables complex parent account <> child account signor access rights (i.e., single signor for transactions below x money, 2/3 multi sig from x > y money, 4/9 multi sig above y, etc.). Parent accounts set conditions and can change conditions. Use of NFTs could give a signer wallet address unique access rights for various accounts within an overall parent structure. For example, a signer wallet address can hold an NFT with a trait providing 1/1 authority at a sub-DAO level but only 4/9 authority at the ultimate parent DAO level.
Protocol enables two way management of money balances to sweep money to a parent cold wallet when not in use or to keep hot wallets funded to certain predetermined levels (if there are regular non programmed money outflows).
The parent economic profile importantly enables aggregated money outflow and money inflow settlement (which would probably occur as part of the Prgrm protocol, discussed in more detail below).
For example, instead of an enterprise or retail parent economic profile sending 20 wires and receiving 30 wires in a single day, these programmed events could be aggregated into batched netted transactions and potentially send one money transfer transaction out and receive one money transfer transaction in. The reduction in transfer transaction fees and possibly currency swap fees may be significant.
One off or ad hoc activities could still be executed at the parent or child level throughout the day, but normal course programmable transactions could be optimized to reduce network fees and congestion.
Rewards for optimizing activity are paid in a commodity or utility token, $TRSRY. When other protocols use the parent <> child match table for various activities, it costs $TRSRY paid to Trsry to do so.
$TRSRY is the governance token of Trsry. There is also a citizen house to guide the long-term agenda of the Trsry ecosystem.
Unclear if the parent <> child match table is a dApp on an existing L2 or a dedicated L2. I’ll table this as part of my next steps to understand technological feasibility, but will assume it’s possible to solve (we’re landing rockets on drone ships in the ocean now…so, should be solvable).
Essentially a security education and / or consulting services organization. Not a protocol or tech platform, but an important element for the apparatus.
Could be multiple levels of service and delivery, but would provide guided educational content for self sovereign security (i.e., basic retail users or SMB level of sophistication). Learn to earn model, paid with $TRSRY rewards as well as reduced Jeprdy costs.
Enterprise or complex retail level key management design and consulting services organization. $TRSRY rewards and reduced Jeprdy costs for participation in initial security assessment and design, annual security consultation and quarterly business reviews of design / architecture. Individual users would also participate for reduced Jeprdy costs. For highly sophisticated users or organizations which prefer a managed service, compensation to KeyMkr may be required.
Protocol enables the sender of funds to program or schedule a future payment (essentially by blind signing a transaction, but → magic → it is super secure) from a child account (or parent account) based on appropriate sender / signer rights. Parent <> child accounts can view all programmed future payments and manage accordingly.
Protocol enables receiver of funds to view pending programmed payments and get visibility into future cash receipts.
Protocol enables both sender and receiver to utilize whichever currency they prefer.
Protocol enables both sender and receiver to pick which L1 / L2 they prefer to send from / receive on.
Protocol enables optimization of settlement execution along three primary axis: (i) reduction of transfer fees by batching sends and receipts to the parent level, (ii) reduction of swap fees by matching batches of send / receive currencies based on a waterfall instead of swapping each individual transaction from one currency to another, and (iii) reduction of bridge fees / bridge security risk by going through the $TRSRY treasury between and among chains. Essentially, all senders send a single transfer (which could cover x individual programmed payments) to a contract address on the respective chain → magic → then all recipients receive a single transfer out of the contract address (which could cover y individual programmed receipts) on the respective chain.
Protocol could also optimize overall network use by running programmed transactions in historically low volume dayparts and by delaying programmed transaction batches if fees are significantly elevated at a certain point in time. Senders and receivers will understand programmed transactions are not instant settle, which is the case with most bill pay or other normal course transactions in TradFi (which is generally fine with me / most financial system users). Prgrmd settlement events could happen throughout the day, multiple times per day or multiple times per hour, or as frequently as settlement volume requires.
Protocol could also enable optimization on one-off or account sweep transactions (e.g., for hot wallet normal funding balances as previously mentioned) by batching them up with regularly scheduled programmed settlements if the sender doesn’t need instant settlement or would like to receive rewards. To some extent, it’s almost like Prgrmd is creating a large mem pool that goes far into the future, but are only sequencing or actioning against the portion of that mem pool that is eligible to settle in the next 12-24 hours for optimization purposes.
As more settlement activity is consolidated on Prgrmd, economies of scale will continue to improve presumably to the point where daily settlement may be economical (i.e., employees receive their salary daily from employers and pay netflix daily for subscription). This level of fluid settlement may remove a lot of complexity and friction around timing of money flows / peak to trough credit needs, and the TradFi ability of entities to exert payment term dominance as a financial value extraction vector (i.e., large companies requiring payment in full up front for one year of service and paying employees every two weeks or vendors every 60+ days).
Even though transactions are batched up to minimize transaction fees, at time of transaction a market clearing fee is charged by Prgrmd and the net amount (after actual network fees) is held in the Prgrmd treasury until periodic rewards are paid (rewards would reflect optimized transaction costs based on use of economic profile to reduce transfers, swaps, etc.).
Other dApps would value historical programmed and unprogrammed money outflow and inflow activity (and mix thereof) as well as programmed future money outflows and inflows. Prgrmd could charge for this information essentially as an oracle or in collaboration with The Graph or a similar decentralized indexing protocol.
Prgrmd’s primary treasury / utility token is $TRSRY, which would be used for rewards payments.
It’s unclear if the programmed future transaction table is a dApp on an existing L2 or a dedicated L2, but this information table is a valuable output (not only for the parent sender and receiver to use, but also for other dApps to leverage).
Number of programmed transactions / value of programmed transactions (both sent and received) could be used as a governance “token” proxy mechanism. Perhaps a Trailing 28 days (T28d) and Trailing 364 days (T364d), or other defined periods, could be used to reward higher levels of recent and / or longer-term engagement. Citizen house would additionally be used for governance.
Protocol provides ongoing risk insurance at the parent <> child level based on multiple on chain variables (e.g., use of Trsry security structure, KeyMkr level of service, parent Rispnsble score, Rispnsble score of frequent transacting counterparties, interactions with nefarious accounts as defined by Confidntl research, mix of programmed vs non programmed transaction activity, past claims history, etc.
Claims will be assessed to understand if the impacted party was targeted and victimized, or if there was a security flaw / general operator error.
Protocol is not permissioned in the sense that you MUST use Jeprdy to transact, but parents with limited history or history of bad behavior may have a very high premium or activities deemed uninsurable.
Insurance for any crypo assets held in CeFi or TradFi or generally off chain will be extremally high, if even available at all. On chain is the way.
Premiums and claim volume will function as a “token” proxy for governance. Citizen house also used for governance.
Rewards system to incentivize parent level entities to behave responsibly on chain and develop a standardized Rispnsble scoring mechanism. Unclear how the score would be stored in the state <> state transition context of blockchains, but presuming primarily programmed settlement activities it could be handled in a pre batch settlement evaluation or something along these lines.
KeyMkr participation increases score, Jeprdy participation increases score, absence of Jeprdy events increases score, higher mix of programmed vs non programmed transactions increases score, T28d vs prior 28 days prgrmd total inflow volume growth and outflow volume decline increases score, T84d vs prior 84 days Prgrmd total inflow volume growth and outflow volume decline increases score, etc.
Participation and positive history interacting with credit extension protocols (introduced next) increases score as well.
API or on chain subgraph account calls (as a user of Rispnsble scores) and calls to community members parent account (as the subject of Rispnsble score evaluation) could be used as a governance “token” proxy. Citizen house would additionally be used.
short term borrowing protocol to extend credit to senders or to modify payment terms to senders preferred frequency.
In the case of normal course credit extension, if a sender has a payment programmed or wants to make a one time payment, but doesn’t have funds on hand, Flowt analyzes programmed future money inflows and outflows at the parent account level and assesses non programmed inflow and outflow history to develop a risk adjusted short term rate. Should be considerably lower than TradFi credit card rates as real time account balance and money flow data is available on chain. The rate could even fluctuate daily if new inflows or outflow are programmed or assets are brough on chain or into the parent structure.
As it relates to sender selection of payment terms, if a sender has an annual subscription one time payment, but would prefer to pay it monthly (or daily), Flowt could pay the recipient on their preferred payment terms (annual up front in this example) and then receive the periodic payments (plus interest) from the sender over the senders preferred payment timeline.
Flowt could probably operate adequately without the benefit of a Rispnsble score given general short term nature and relatively small individual transaction size, but high Rispnsble score could also be a factor for interest rate pricing.
Trsry community members can opt into Flowt pools to receive $TRSRY rewards / yield. Rewards required to be paid in $TRSRY for Flowt to leverage the (i) parent <> child account match table and (ii) future programmed payments information.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Enterprise grade short term borrowing solution in the event payment cycles are less frequent or have greater cash flow peak to trough amplitude than Flowt can price reasonably.
May require securitization into Revlvr + borrower multi-sig account for portion of liquidity, review of off chain financial profile and decentralized oracle data feed to balances, etc.
Trsry community members can opt into Revlvr pools to receive $TRSRY rewards.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Enterprise grade credit facility for longer duration financing needs to fund investment in future operations greater than short term liquidity needs. Would likely require some pledge of off chain assets, perhaps posted as NFTs into a multi-sig with borrower and Invest as 2/2 signers.
Trsry community members can opt into Invst pools to receive $TRSRY rewards.
Loan “paper” may be represented as NFTs collections with the traits of the individual NFT reflecting the terms (i.e., notional amount is par value, coupon rate is interest payment, fixed vs variable rate, maturity date, amortization payment cadence, interest payment cadence, current vs default, etc.). Risponsble score will be a trait and metadata will update frequently, creating a more easily valuable security for liquid trading via DEX.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Liquid staking as a service and / or liquid mining as a service protocol with a key mandate of promoting decentralization across all networks it participates in security / block production / consensus.
$liETH, $liDAI, $liBTC, $liUSDT, $liUSDC, etc. Protocol would use native coins (i.e., $ETH) to stake PoS, provide swap pool liquidity, low risk loan lending, mining operations, etc., to back liquid tokens to generate attractive unlevered yields on major crypto assets.
$liXXX liquid assets would be preferred assets used across all dApps within the apparatus and receive $TRSRY rewards for use (in addition to native token yield, where applicable).
Crypto community members have raised concerns about liquid staking as a centralization risk vector, so Liqd would use economic disincentives / incentives or governance mandated altruistic actions to promote diverse staking community. For example, if Liqd $liETH becomes too concentrated (i.e., greater than 15% of staked ETH), Liqd will (i) reduce $TRSRY rewards on $liETH, (ii) increase Liqd commission on $liETH (reducing yield to holder), (iii) unstake ETH and use to buy stETH or rETH, etc.
A long-term goal for Liqd would be to create a portfolio of tracker tokens which seek to reflect purchasing power in various jurisdictions. For example, instead of simply a stable coin that is pegged to a fiat currency, creation of a tracker token that reflects changes in purchase power or inflation in a country or region, with a collar around movements to allow for drift and promote general price stability. No clue what this mechanism would be or if it’s possible, but this does seem like an better alternative to fiat stable coins as the related fiat currencies can be debased or generally not track actual purchase power.
Token house governance could be led at the individual liXXX token level based on holders (i.e., 1 token = 1 vote), which would operate almost as sub token houses. The Liqd protocol total token house would be an aggregation of al sub token houses (i.e., total tokens across all liXXX tokens. Individual liXXX and Liqd in total would have a citizen house.
Alternative to Tornado cash. Goal is to engage with regulators to develop a set of parameters whereby if adequate evidence of fraud or wrongdoing is provided related to an account / transaction, Confidntl would provide the breadcrumbs for researchers to match the input amount to the resulting confidential output amounts / accounts.
This wouldn’t provide an actual KYC name or personal information, but presumably would enable the researcher to trace those accounts to interactions with other accounts / CEXs to discover government identity. You know, good old fashioned police work.
For example, if an evidence threshold is met and the community votes to provide support, a private chain or some sort of zero knowledge proof could be called on to provide the algorithm configuration at the time of the subject transaction (i.e., the algorithm was (i) split into seven accounts, (ii) based on an arithmetic sequence, (iii) starting at 10% of the total, (iv) adding 3% with each progression, (v) with the remainder going into the seventh account, (vi) settled 189 minutes after deposit into Confidntl. Based on this knowledge, the government researchers should be able to review the on chain activity and piece together the seven resulting account numbers and continue to do good old fashioned police work.
To fund the project and to deter bad actors from using Confidntl, fees paid into this protocol should initial be meaningfully greater than less altruistic protocols. As such, community members that deeply care about confidentiality and not simply trying to evade authorities will happily pay the higher costs. Everyone else will likely choose cheaper alternatives.
The higher fees will be used to (i) refine the tech, (ii) coordinate with regulators to activate cooperation framework, (iii) fund broad ecosystem research across all protocols and mixer tools to support community self policing (i.e., track and trace activities inbound and outbound of other mixer protocols to support authorities with investigations of wrong doing around those protocols).
Once the tech is well developed, framework set with regulators, and ecosystem research approach well oiled, fees can be reduced to a very small amount. However, now that bad actors know they can be exposed to authorities, they will likely continue to avoid use of the protocol.
It’s likely that very few good actors will ever be probed within Confidntl, and that an even smaller subset of them will reach the required evidentiary threshold for cooperation with authorities. As a result, the protocol enables confidential transactions rivaling the current option of fiat currency cash with the benefits of self custody and on chain convenience.
That was a lot to digest, I’m sure. Here is an attempt at a matrix to summarize
I have no idea.
As I continue my Web3 journey, I’ll be researching this question, re: the apparatus, among other topics. The technological questions I currently have are:
Do the Trsry (parent account match) and Prgrmd (future payments) proprietary data tables need to exist on isolated L1s / L2s / other? Could the state → state transitions of these table live on existing block chains?
Are there actually savings from pooling lots of payments into a single settlement event?
If pooling transactions is economical, it seems like it would still be a huge sequence of transactions subject to MEV, so would it need to be fully settled on a single chain? And wouldn’t that lead to extreme centralization? Or the need to rebuild the security of sequencing and validating for this use case?
Can Rispnsble scores or real time credit extension in Flowt be managed in a state <> state transition environment when settling a large amount of transactions (i.e., maybe Flowt credit is not needed so no assessment is required, perhaps a parent <> child is not paying for Jeprdy insurance so Rispnsble score is not relevant, etc.)
Can loans between Trsry treasury and Trsry parent accounts facilitate cross chain bridging with an optimized security footprint?
I’m sure I’ll develop more as I progress, but this are my current quagmires.
So far my mirror posts have essentially been a stream of consciousness with very limited research to support my assertions or conclusions. In the next phase of my exploration I will spend more time looking for existing research, solutions, and conclusions on three batches of topics:
I’ll look for current or proposed solutions which address the various protocols or tools I’ve introduced above, which are:
Trsry
KeyMkr
Prgrmd
Jeprdy
Rispnsble
Flowt
Revlvr
Invst
Liqd
Confidntl
In a previous post, I outlined a few problems which I think would be great to solve in the short term to accelerate adoption. These problems were:
Fiat on-ramp fees
Direct deposit options
Net yield on capital
Settlement of key payments
Fiat off-ramp fees
In a previous post, I defined the features that I value from TradFi and compared them to Crypto / Web3, which were:
Physical / digital asset security
Catastrophic event insurance
Asset portability and transmissibility
Access to credit
Permission / validation of credible parties
Ability to transact anonymously
Reasonable compensation for use of funds
There is a fair amount of overlap between these three sets of topics, so as I progress I will address multiple topics from these three topic groupings per individual post, as applicable.
What did I leave out and need to address? Reply to the companion TWEET to this post so I’m on the right path!
About the This Web3 Life collection:
About rasmuky:
I’ve now been immersed in Web3 for about eight months and have learned a lot about many of the fundamental technologies, frameworks, protocols and theories of the space. Throughout this time I’ve explored a number of use cases in my mind and considered how some may interconnect to strengthen network effects and general value propositions of individual protocols.
This post is my attempt to organize these thoughts into a Frankenstein’s monster apparatus and chart the path to research the technological, psychological, and economical challenges to creation of such an apparatus.
The foundational attributes of the monster which I’m most excited about are:
I think creation of a user self reported and managed “economic profile” is important to a healthy and optimized financial system on chain. Building credibility over time with responsible behavior enables users and protocols to interact more fluidly and efficiently while remaining permissionless, trustless, and undercollateralized (or most importantly not overcollateralized)
An economic profile does not have to equal identity…even anons can build financial credibility and creditworthiness simply by behaving responsibly
A dApp which enables robust programming of future money inflows and money outflows between and among various end use parties (i.e., with no intermediaries) would be new economic information not currently captured in the off-chain CeFi or TradFi environment. This could scale on-chain and be a valuable input to credit extension and the flow of commerce
A network of dApps which benefit from visibility into an economic profile can leverage features / data from one another and pay rewards in a common utility token. It’s possible that value accrual to a common utility token alone would incentivize a broad range of dApps to participate, or dApp to dApp payments for data could be an option as well
For dApps with common utility token, individual protocol governance could be driven by dApp use instead of basic hodling of an individual dApp’s utility / governance tokens. This drives influence to the users of the respective protocol instead of the hodlers of capital
Larger dApps within the common utility token apparatus will likely hold more of the primary utility token within an individual dApp treasury to facilitate periodic rewards funding, thus increasing governance influence over the common utility token for the larger dApps in the apparatus
The mosaic idea within this post is essentially unresearched at this point.
This apparatus is simply thoughts from my head now on digital paper. My commitment as a next steps is to do the research on technological feasibility, existing protocols in development, psychological / economical / political traps, and general evaluation of the major concepts to assess if there is something more to explore and build.
Any thoughts, feedback, critiques, memes you may have are welcomed in the replies to the companion TWEET to this post. #Learning.
I don’t know why, but when I let my mind wander I tend to dream up complex interconnected systems. I know, I have a problem…but it’s a thing I do.
So, I dreamt up this monster I call the Apparatus:
I think of it as a first draft which combines (i) my interpretation of some Web3 ecosystem fundamentals and (ii) what I initially want from the technology (which is also what I personally think will help to drive broad adoption).
Some context:
All of the protocols / dApps in the image above are introduced / explained below. I thought it might be helpful to the reader to get a basic visual of the full apparatus for reference
The image above displays a single chain architecture (e.g., what you would see on Optimism L2)
Expectation is the apparatus would be made composable or adoptable across all chains to provide a chain agnostic view of a Trsry parent account economic profile
Added benefit of chain agnostic composability is ability to bridge cross chain through protocol / smart contract layer Trsry treasury via “bridge” liquidity partner loans
Is the safest way to bridge between chains to not bridge at all?
This is not a comprehensive list of the pros and cons, but highlights a few topics which seem most radical relative to current ecosystem user expectations and / or critical to usefulness of the apparatus:
Anons, retail users, and enterprise users will agree to link wallets or account numbers to create an economic profile and will receive rewards for utilizing dApps and credit availability benefits in return for participation
Institutional and retail users will embrace self custody accounts, account substructures, single signor and multi signor key application and key management best practices to optimize security
Or, at least be open to an alternative to custody solutions between self custody and centralized custody. It seems current conventional wisdom doesn’t leave much room for an alternative framework to self custody or centralized custody
Enough activity can move and remain on chain to make settlement effective, efficient, and economical.
No need for a separate payroll direct deposit option if employers are settling all types of payments on chain
No need for cheap fiat on-ramps and off-ramps if a lot of end use settlement can occur natively on chain
Protocols will see enough value in leveraging parent account match tables and programmed transaction information to adopt a common token for rewards
It is technologically possible to store on chain (or via a private chain or zero knowledge chain) various new states or parent account attributes which can be called / evaluated in real time (efficiently) to enable decision making
If a responsibility or credit score is maintained, where is the state of the parent economic profile stored? How is state transition processed? How do other apps call the state or recent trend in the state? etc.
Similar questions for how to store, maintain history, process state change, and call on for other dApp use other information (e.g., programmed future payments)
A common rewards token treasury can be used across all chains as a secure alternative to bridging
Productive coordination with various governmental institutions is achievable in order to (i) support investigation of bad actors and (ii) facilitate private, human rights enabling, transactions from good actors
The outline below introduces a number of theoretical protocols / organizations which can generally operate independently. There could even be multiple competing versions of the individual topical organizations. However, all protocols (with the exception of Confidntl) foundationally leverage as key information (i) the economic profile enabled by Trsry and (ii) programmed money inflows and money outflows enabled by Prgrmd.
Protocol enables wallet address / account number aggregation to an economic profile (referred to as “parent”). Child accounts sign access control to parent account similar to a blind signing concept. Parent accounts can rescind access control or “revoke cash” to a child if requested and approved. A child account can only have one parent, but parent accounts can have multiple children. A parent account with children can be a child account to an ultimate parent (i.e., a sub-DAO “parent” account can have child accounts and an actionable economic profile at that sub-DAO level, but said account can also be a child to the top DAO parent account).
Protocol enables complex parent account <> child account signor access rights (i.e., single signor for transactions below x money, 2/3 multi sig from x > y money, 4/9 multi sig above y, etc.). Parent accounts set conditions and can change conditions. Use of NFTs could give a signer wallet address unique access rights for various accounts within an overall parent structure. For example, a signer wallet address can hold an NFT with a trait providing 1/1 authority at a sub-DAO level but only 4/9 authority at the ultimate parent DAO level.
Protocol enables two way management of money balances to sweep money to a parent cold wallet when not in use or to keep hot wallets funded to certain predetermined levels (if there are regular non programmed money outflows).
The parent economic profile importantly enables aggregated money outflow and money inflow settlement (which would probably occur as part of the Prgrm protocol, discussed in more detail below).
For example, instead of an enterprise or retail parent economic profile sending 20 wires and receiving 30 wires in a single day, these programmed events could be aggregated into batched netted transactions and potentially send one money transfer transaction out and receive one money transfer transaction in. The reduction in transfer transaction fees and possibly currency swap fees may be significant.
One off or ad hoc activities could still be executed at the parent or child level throughout the day, but normal course programmable transactions could be optimized to reduce network fees and congestion.
Rewards for optimizing activity are paid in a commodity or utility token, $TRSRY. When other protocols use the parent <> child match table for various activities, it costs $TRSRY paid to Trsry to do so.
$TRSRY is the governance token of Trsry. There is also a citizen house to guide the long-term agenda of the Trsry ecosystem.
Unclear if the parent <> child match table is a dApp on an existing L2 or a dedicated L2. I’ll table this as part of my next steps to understand technological feasibility, but will assume it’s possible to solve (we’re landing rockets on drone ships in the ocean now…so, should be solvable).
Essentially a security education and / or consulting services organization. Not a protocol or tech platform, but an important element for the apparatus.
Could be multiple levels of service and delivery, but would provide guided educational content for self sovereign security (i.e., basic retail users or SMB level of sophistication). Learn to earn model, paid with $TRSRY rewards as well as reduced Jeprdy costs.
Enterprise or complex retail level key management design and consulting services organization. $TRSRY rewards and reduced Jeprdy costs for participation in initial security assessment and design, annual security consultation and quarterly business reviews of design / architecture. Individual users would also participate for reduced Jeprdy costs. For highly sophisticated users or organizations which prefer a managed service, compensation to KeyMkr may be required.
Protocol enables the sender of funds to program or schedule a future payment (essentially by blind signing a transaction, but → magic → it is super secure) from a child account (or parent account) based on appropriate sender / signer rights. Parent <> child accounts can view all programmed future payments and manage accordingly.
Protocol enables receiver of funds to view pending programmed payments and get visibility into future cash receipts.
Protocol enables both sender and receiver to utilize whichever currency they prefer.
Protocol enables both sender and receiver to pick which L1 / L2 they prefer to send from / receive on.
Protocol enables optimization of settlement execution along three primary axis: (i) reduction of transfer fees by batching sends and receipts to the parent level, (ii) reduction of swap fees by matching batches of send / receive currencies based on a waterfall instead of swapping each individual transaction from one currency to another, and (iii) reduction of bridge fees / bridge security risk by going through the $TRSRY treasury between and among chains. Essentially, all senders send a single transfer (which could cover x individual programmed payments) to a contract address on the respective chain → magic → then all recipients receive a single transfer out of the contract address (which could cover y individual programmed receipts) on the respective chain.
Protocol could also optimize overall network use by running programmed transactions in historically low volume dayparts and by delaying programmed transaction batches if fees are significantly elevated at a certain point in time. Senders and receivers will understand programmed transactions are not instant settle, which is the case with most bill pay or other normal course transactions in TradFi (which is generally fine with me / most financial system users). Prgrmd settlement events could happen throughout the day, multiple times per day or multiple times per hour, or as frequently as settlement volume requires.
Protocol could also enable optimization on one-off or account sweep transactions (e.g., for hot wallet normal funding balances as previously mentioned) by batching them up with regularly scheduled programmed settlements if the sender doesn’t need instant settlement or would like to receive rewards. To some extent, it’s almost like Prgrmd is creating a large mem pool that goes far into the future, but are only sequencing or actioning against the portion of that mem pool that is eligible to settle in the next 12-24 hours for optimization purposes.
As more settlement activity is consolidated on Prgrmd, economies of scale will continue to improve presumably to the point where daily settlement may be economical (i.e., employees receive their salary daily from employers and pay netflix daily for subscription). This level of fluid settlement may remove a lot of complexity and friction around timing of money flows / peak to trough credit needs, and the TradFi ability of entities to exert payment term dominance as a financial value extraction vector (i.e., large companies requiring payment in full up front for one year of service and paying employees every two weeks or vendors every 60+ days).
Even though transactions are batched up to minimize transaction fees, at time of transaction a market clearing fee is charged by Prgrmd and the net amount (after actual network fees) is held in the Prgrmd treasury until periodic rewards are paid (rewards would reflect optimized transaction costs based on use of economic profile to reduce transfers, swaps, etc.).
Other dApps would value historical programmed and unprogrammed money outflow and inflow activity (and mix thereof) as well as programmed future money outflows and inflows. Prgrmd could charge for this information essentially as an oracle or in collaboration with The Graph or a similar decentralized indexing protocol.
Prgrmd’s primary treasury / utility token is $TRSRY, which would be used for rewards payments.
It’s unclear if the programmed future transaction table is a dApp on an existing L2 or a dedicated L2, but this information table is a valuable output (not only for the parent sender and receiver to use, but also for other dApps to leverage).
Number of programmed transactions / value of programmed transactions (both sent and received) could be used as a governance “token” proxy mechanism. Perhaps a Trailing 28 days (T28d) and Trailing 364 days (T364d), or other defined periods, could be used to reward higher levels of recent and / or longer-term engagement. Citizen house would additionally be used for governance.
Protocol provides ongoing risk insurance at the parent <> child level based on multiple on chain variables (e.g., use of Trsry security structure, KeyMkr level of service, parent Rispnsble score, Rispnsble score of frequent transacting counterparties, interactions with nefarious accounts as defined by Confidntl research, mix of programmed vs non programmed transaction activity, past claims history, etc.
Claims will be assessed to understand if the impacted party was targeted and victimized, or if there was a security flaw / general operator error.
Protocol is not permissioned in the sense that you MUST use Jeprdy to transact, but parents with limited history or history of bad behavior may have a very high premium or activities deemed uninsurable.
Insurance for any crypo assets held in CeFi or TradFi or generally off chain will be extremally high, if even available at all. On chain is the way.
Premiums and claim volume will function as a “token” proxy for governance. Citizen house also used for governance.
Rewards system to incentivize parent level entities to behave responsibly on chain and develop a standardized Rispnsble scoring mechanism. Unclear how the score would be stored in the state <> state transition context of blockchains, but presuming primarily programmed settlement activities it could be handled in a pre batch settlement evaluation or something along these lines.
KeyMkr participation increases score, Jeprdy participation increases score, absence of Jeprdy events increases score, higher mix of programmed vs non programmed transactions increases score, T28d vs prior 28 days prgrmd total inflow volume growth and outflow volume decline increases score, T84d vs prior 84 days Prgrmd total inflow volume growth and outflow volume decline increases score, etc.
Participation and positive history interacting with credit extension protocols (introduced next) increases score as well.
API or on chain subgraph account calls (as a user of Rispnsble scores) and calls to community members parent account (as the subject of Rispnsble score evaluation) could be used as a governance “token” proxy. Citizen house would additionally be used.
short term borrowing protocol to extend credit to senders or to modify payment terms to senders preferred frequency.
In the case of normal course credit extension, if a sender has a payment programmed or wants to make a one time payment, but doesn’t have funds on hand, Flowt analyzes programmed future money inflows and outflows at the parent account level and assesses non programmed inflow and outflow history to develop a risk adjusted short term rate. Should be considerably lower than TradFi credit card rates as real time account balance and money flow data is available on chain. The rate could even fluctuate daily if new inflows or outflow are programmed or assets are brough on chain or into the parent structure.
As it relates to sender selection of payment terms, if a sender has an annual subscription one time payment, but would prefer to pay it monthly (or daily), Flowt could pay the recipient on their preferred payment terms (annual up front in this example) and then receive the periodic payments (plus interest) from the sender over the senders preferred payment timeline.
Flowt could probably operate adequately without the benefit of a Rispnsble score given general short term nature and relatively small individual transaction size, but high Rispnsble score could also be a factor for interest rate pricing.
Trsry community members can opt into Flowt pools to receive $TRSRY rewards / yield. Rewards required to be paid in $TRSRY for Flowt to leverage the (i) parent <> child account match table and (ii) future programmed payments information.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Enterprise grade short term borrowing solution in the event payment cycles are less frequent or have greater cash flow peak to trough amplitude than Flowt can price reasonably.
May require securitization into Revlvr + borrower multi-sig account for portion of liquidity, review of off chain financial profile and decentralized oracle data feed to balances, etc.
Trsry community members can opt into Revlvr pools to receive $TRSRY rewards.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Enterprise grade credit facility for longer duration financing needs to fund investment in future operations greater than short term liquidity needs. Would likely require some pledge of off chain assets, perhaps posted as NFTs into a multi-sig with borrower and Invest as 2/2 signers.
Trsry community members can opt into Invst pools to receive $TRSRY rewards.
Loan “paper” may be represented as NFTs collections with the traits of the individual NFT reflecting the terms (i.e., notional amount is par value, coupon rate is interest payment, fixed vs variable rate, maturity date, amortization payment cadence, interest payment cadence, current vs default, etc.). Risponsble score will be a trait and metadata will update frequently, creating a more easily valuable security for liquid trading via DEX.
Value of loans outstanding (as a lender) could be used as a governance “token”. Citizen house would additionally be used.
Liquid staking as a service and / or liquid mining as a service protocol with a key mandate of promoting decentralization across all networks it participates in security / block production / consensus.
$liETH, $liDAI, $liBTC, $liUSDT, $liUSDC, etc. Protocol would use native coins (i.e., $ETH) to stake PoS, provide swap pool liquidity, low risk loan lending, mining operations, etc., to back liquid tokens to generate attractive unlevered yields on major crypto assets.
$liXXX liquid assets would be preferred assets used across all dApps within the apparatus and receive $TRSRY rewards for use (in addition to native token yield, where applicable).
Crypto community members have raised concerns about liquid staking as a centralization risk vector, so Liqd would use economic disincentives / incentives or governance mandated altruistic actions to promote diverse staking community. For example, if Liqd $liETH becomes too concentrated (i.e., greater than 15% of staked ETH), Liqd will (i) reduce $TRSRY rewards on $liETH, (ii) increase Liqd commission on $liETH (reducing yield to holder), (iii) unstake ETH and use to buy stETH or rETH, etc.
A long-term goal for Liqd would be to create a portfolio of tracker tokens which seek to reflect purchasing power in various jurisdictions. For example, instead of simply a stable coin that is pegged to a fiat currency, creation of a tracker token that reflects changes in purchase power or inflation in a country or region, with a collar around movements to allow for drift and promote general price stability. No clue what this mechanism would be or if it’s possible, but this does seem like an better alternative to fiat stable coins as the related fiat currencies can be debased or generally not track actual purchase power.
Token house governance could be led at the individual liXXX token level based on holders (i.e., 1 token = 1 vote), which would operate almost as sub token houses. The Liqd protocol total token house would be an aggregation of al sub token houses (i.e., total tokens across all liXXX tokens. Individual liXXX and Liqd in total would have a citizen house.
Alternative to Tornado cash. Goal is to engage with regulators to develop a set of parameters whereby if adequate evidence of fraud or wrongdoing is provided related to an account / transaction, Confidntl would provide the breadcrumbs for researchers to match the input amount to the resulting confidential output amounts / accounts.
This wouldn’t provide an actual KYC name or personal information, but presumably would enable the researcher to trace those accounts to interactions with other accounts / CEXs to discover government identity. You know, good old fashioned police work.
For example, if an evidence threshold is met and the community votes to provide support, a private chain or some sort of zero knowledge proof could be called on to provide the algorithm configuration at the time of the subject transaction (i.e., the algorithm was (i) split into seven accounts, (ii) based on an arithmetic sequence, (iii) starting at 10% of the total, (iv) adding 3% with each progression, (v) with the remainder going into the seventh account, (vi) settled 189 minutes after deposit into Confidntl. Based on this knowledge, the government researchers should be able to review the on chain activity and piece together the seven resulting account numbers and continue to do good old fashioned police work.
To fund the project and to deter bad actors from using Confidntl, fees paid into this protocol should initial be meaningfully greater than less altruistic protocols. As such, community members that deeply care about confidentiality and not simply trying to evade authorities will happily pay the higher costs. Everyone else will likely choose cheaper alternatives.
The higher fees will be used to (i) refine the tech, (ii) coordinate with regulators to activate cooperation framework, (iii) fund broad ecosystem research across all protocols and mixer tools to support community self policing (i.e., track and trace activities inbound and outbound of other mixer protocols to support authorities with investigations of wrong doing around those protocols).
Once the tech is well developed, framework set with regulators, and ecosystem research approach well oiled, fees can be reduced to a very small amount. However, now that bad actors know they can be exposed to authorities, they will likely continue to avoid use of the protocol.
It’s likely that very few good actors will ever be probed within Confidntl, and that an even smaller subset of them will reach the required evidentiary threshold for cooperation with authorities. As a result, the protocol enables confidential transactions rivaling the current option of fiat currency cash with the benefits of self custody and on chain convenience.
That was a lot to digest, I’m sure. Here is an attempt at a matrix to summarize
I have no idea.
As I continue my Web3 journey, I’ll be researching this question, re: the apparatus, among other topics. The technological questions I currently have are:
Do the Trsry (parent account match) and Prgrmd (future payments) proprietary data tables need to exist on isolated L1s / L2s / other? Could the state → state transitions of these table live on existing block chains?
Are there actually savings from pooling lots of payments into a single settlement event?
If pooling transactions is economical, it seems like it would still be a huge sequence of transactions subject to MEV, so would it need to be fully settled on a single chain? And wouldn’t that lead to extreme centralization? Or the need to rebuild the security of sequencing and validating for this use case?
Can Rispnsble scores or real time credit extension in Flowt be managed in a state <> state transition environment when settling a large amount of transactions (i.e., maybe Flowt credit is not needed so no assessment is required, perhaps a parent <> child is not paying for Jeprdy insurance so Rispnsble score is not relevant, etc.)
Can loans between Trsry treasury and Trsry parent accounts facilitate cross chain bridging with an optimized security footprint?
I’m sure I’ll develop more as I progress, but this are my current quagmires.
So far my mirror posts have essentially been a stream of consciousness with very limited research to support my assertions or conclusions. In the next phase of my exploration I will spend more time looking for existing research, solutions, and conclusions on three batches of topics:
I’ll look for current or proposed solutions which address the various protocols or tools I’ve introduced above, which are:
Trsry
KeyMkr
Prgrmd
Jeprdy
Rispnsble
Flowt
Revlvr
Invst
Liqd
Confidntl
In a previous post, I outlined a few problems which I think would be great to solve in the short term to accelerate adoption. These problems were:
Fiat on-ramp fees
Direct deposit options
Net yield on capital
Settlement of key payments
Fiat off-ramp fees
In a previous post, I defined the features that I value from TradFi and compared them to Crypto / Web3, which were:
Physical / digital asset security
Catastrophic event insurance
Asset portability and transmissibility
Access to credit
Permission / validation of credible parties
Ability to transact anonymously
Reasonable compensation for use of funds
There is a fair amount of overlap between these three sets of topics, so as I progress I will address multiple topics from these three topic groupings per individual post, as applicable.
What did I leave out and need to address? Reply to the companion TWEET to this post so I’m on the right path!
About the This Web3 Life collection:
About rasmuky:
<100 subscribers
<100 subscribers
No activity yet