This is our regular monthly progress report for Autark and Open Work Labs' work on AGP-19, which was funded via Aragon Network Vote #1. This post is broken down into the initiatives in our original proposal. You can review previous updates here: May 2019, April 2019, March 2019.
Last month we had a much needed offsite and our major activities were planning the proposal for our next AGP, talking through some of our existing features like contextual discussions, hacking together IPFS nodes, and... not so major, but we also bonded over episodes of Black Mirror in the late evenings.
Our team is growing: Chad Ostrowski, frontend engineer, joined at the end of May; Javier Alaves, product designer, joined early June; and now Ola Kohut, ecosystem strategy lead, joined us part-time last week. We are stoked that they were all interested in joining us with only 1-2 months of runway left. Some bios:
- Chad is a front-end engineer with four years of ReactJS expertise and nine total years of full stack web engineering experience. He enjoys teaching and speaking, having delivered well-received talks on web3 architectures and humanity’s future in space.
- Javier is a product and UX designer that has previously cofounded two successful startups as a multidisciplinary design strategist. For the past two years he has been researching and designing economic models and tools related to distributed systems.
- Ola is a research, strategy, growth and online community building professional with a background in public policy & international relations. For the past two years she has been working to bring the Web3 paradigm into reality, having worked for Tendermint, Status as well as Epicenter podcast.
Check out our next Flock proposal, and let us know what you think! We are also holding an AMA on YouTube Live this Friday July 5th at 4:30PM CEST.
June 2019 Progress Report
I01 - Cross-Application User Experience
The majority of the Dynamic Forwarding work has been completed and we are now working on integrating Dynamic Forwarding into Dot Voting. In June we've created a new execution type for forwarders and are excited to see how developers and the community respond to the new forwarder patterns that this will allow.
For what we have scoped in AGP-19, we feel that this initiative is close to completion, with PR reviews, integrations, and testing remaining. A summary of our deliverables:
- Forwarder API: Makes data accessible for actions that have been forwarded to another app (aragon.js PR)
- External intents: Ability for an app to interact with an external contract (aragon.js PR, aragon client PR). This was developed to support contextual discussions, and we believe a good step toward multi-contract Aragon apps.
- Dynamic Forwarding: Allow for more tightly coupled forwarder interactions where the forwarded call data can actually be leveraged and modified within the Forwarder contract. (in the process of preparing an aragonOS PR)
All of the features described above will be showcased in a revamped Dot Voting app. While this initiative is close to completion for the deliverables we have scoped, we see it as a continuous effort, as we don't think cross application UX is close to being solved at a macro level. As an added bonus: we are developing solutions for deep linking that we will share in our next update.
Review May 2019 update
aragonAPI: Forwarder API
Currently, if you create a transfer using the Finance app which requires a vote for approval, the Finance app will have no knowledge of this transfer until the vote concludes. This is due to limitations in the API where data is not accessible for actions that have been forwarded to another app. The enhancement we have developed, the Forwarder API, will enable application developers to implement more traditional web experiences, where members of a DAO will have better knowledge of the pending actions within the application that originated the action.
We have completed development of the API, which generally follows the specification outlined by Brett on the Aragon forum, and submitted a PR to aragon.js which is pending review. This API will be a very useful tool for us to eventually display actionable data within the Home app and hence supports our Organization Identity initiative as well.
We've started initial work on Dynamic Forwarding with aimed completion of the initial spec ready for review by our next monthly update. These changes will allow for more interesting forwarder interactions and allow access to application defined options to unfold in forwarder applications. Once developers have these tools they'll be able to change the way forwarded actions are executed based on the state of the forwarder at the time of execution. This will allow for increased experimentation with non-boolean voting patterns.
Review April 2019 updateBased on development survey results and our own experience developing Aragon apps, we published a forum post that describes features that will be important to enhance the user experience for Aragon users.
After further review, we have decided to prioritize the development work based on our other initiatives that are dependent on these enhancements. Hence our initial focus will be areas that are related toward the Organization Identity initiative.
Read more in the I06 section of this update for details.
Review March 2019 updateWe created a survey to understand the developer’s experience with creating Aragon apps and received five responses. We are in the process of writing a report for the forum which will synthesize the findings from the survey along with notes from a meeting that took place at the end of January at AraCon. The purpose of this report is to discuss our recommendations with the broader community which will lead toward a spec to enhance the aragonAPI and Forwarder, to deliver on our Cross Application User Experience initiative.
Since our report is still in progress, we are still accepting answers to our survey. If you have experience developing Aragon apps, please participate — it should take no longer than 5–10 mins.
A major limitation of the Aragon architecture is the tight coupling between an individual application front-end and contract. With this limitation, there is less freedom to design feature sets with the optimal user experience, where multiple contracts may be more logical for a single application.
To improve upon the architecture, aragonAPI will be modified so as to support both relationships between a single app front-end and multiple contracts, as well as add tools to allow for contract data to be displayed across multiple user interfaces without coupling at the contract level.
Once the flow has been defined within aragonAPI we will create at least one example of how we see ideal one-to-many and many-to-one relationships working.
Expanded Forwarder Options
Currently the forwarder is mainly designed to pass isolated actions where the forwarder has little to no knowledge of the forwarded action. We will research potential ways to expand its usability by creating additional specifications for script execution. This will allow for more tightly coupled forwarder interactions where the forwarded call data can actually be leveraged and modified within the Forwarder contract.
At minimum we will design the specification and implement it in aragonOS for forwarder interactions that expect data to be passed between the forwarding and forwarder contracts at the contract level.
I02 - Contextual Discussions
The technical architecture behind contextual discussions has evolved since we started. Originally, we imagined a centralized query layer built on top of IPFS to support discussions. But after publishing our ideas in more depth, the community seemed to prefer more decentralized approaches. We researched Textile, OrbitDB, and 3Box and published our key findings (OrbitDB and Textile notes; 3box notes).
In short, Textile (originally designed for mobile environments) won't work for Aragon apps yet because each user would need to run a node locally on their machine. Orbit and 3Box don't integrate easily with Aragon apps because they require access to storage APIs, which are restricted in Aragon app iframes. The next best option is to use smart contracts.
So in June we built a proof of concept contextual discussion app using smart contracts. This required a few feature additions to Aragon to support external intents that we described in I01. Most importantly, an Aragon application will soon be able to initiate transactions with external smart contracts (currently, an Aragon application is closely tied with a single contract).
Getting this to work in a dynamic and secure way required some other additions as well. If you’re interested in more information, here are the pull requests (which were also linked in I01 above):
In July we are working on building easy to import UI and state building modules for adding contextual discussions into your own Aragon application.
Review May 2019 update
There are no additional updates since our previous report. This work is expected to continue mid-June, once Profiles is in a more finalized state.
Review April 2019 updateAs mentioned in our March update, we completed the technical spec for discussions. This month there has not been any development work directly related to discussions, although there has been dependent work that this initiative is consuming from the Data Storage initiative. Read more in the I05 section of this update for details.
We plan on beginning Discussions application development work after completing the Profiles initiative.
Review March 2019 updateFor discussions, we created a V1 spec for a traditional database that stores data on IPFS and resolves requests for content through hashes, not arbitrary IDs. This is in tune with what we proposed as the “short term” solution in our Flock proposal.
Review AGP-19Many applications throughout Aragon would benefit from contextual discussions or commenting. For example, if there is a transaction displayed in the Finance app, a member of the organization may be interested in beginning a discussion related to a transaction in the table. Additionally, Votes, Surveys, and Range Votes will all benefit from having the discussion located within Aragon.
At the high level, discussion capabilities will have:
- Ability to add, edit and delete comments
- Support for markdown
- Ability to like comments, weighted by the amount of DAO’s tokens held at time of snapshot based on context
I03 - Rich User Profiles
In June we have been putting the final touches on our Aragon Profile app. We converted it into a node module so it can be imported into the Aragon Client, making it easier to maintain in the near-term before it becomes fully part of the client.
We’ve also been fixing small bugs and making performance improvements. There are a few issues left to be worked out with Aragon One on finalizing the profile integration; more information can be found in this pull request.
Review May 2019 update**Progress: 70%**
Profiles in Aragon are nearly feature complete, and we've started to integrate our work into Aragon client. A user can associate information about themselves to an Ethereum address including a name, bio, website, location, work and education history, and also a profile and cover photo! Since the profiles are built using 3Box, a user's profile from Aragon will appear on any other application using 3Box for profiles.
Review April 2019 updateWe began development of the Profile app and completed the 3box integration; right now we are building out the remaining frontend features.
To support this effort, we submitted 3 PRs to Aragon repositories to integrate signing arbitrary message into Aragon, in attempt to make Profiles compatible with 3box:
While we began the prototype as an app, we think that profiles should be included in the Aragon client, as the MVP of a user profile is organization-agnostic. We plan to present our case for this in the coming weeks.
Review March 2019 updateSo far, we’ve created a complete profile spec as well as a proof of concept application that scrapes profile data from LinkedIn, formats it according to linked data standards, and stores it in a 3box profile. Unfortunately, LinkedIn’s developer program rejected our request to use their full profile API, so we will not be integrating with them. Once message signing within Aragon is resolved, we can implement 3box in an Aragon app.
Review AGP-19While Aragon One’s identity app will provide much-needed features; an identity is more than a name, bio, ENS domain, and avatar. We propose to expand identities to allow for more rich profiles. This will be useful as the network of organizations within Aragon grows and a freelancer culture develops. This supplementary data can be useful in assessing allegiances, expertise, and clout.
The additional data elements that will be relevant to expose in relation to a profile can be:
- Memberships to other Aragon DAOs
- Work Experience
- Ability to import data from LinkedIn or manually input work experience
- Ability to import commit history from Github, highlighting top projects
- Ability to curate an portfolio of images (such as design work) hosted on distributed storage
I04 - Expanding Governance
We solidified a strategy for quasi-transferable tokens that will allow for both recipient and sender whitelisting with only modifications to the TokenManager and not the token contract itself. We should have the initial proof of concept for quasi-transferable tokens (and as a result reputation within Aragon) by next month's update.
Note: in our previous update we mentioned the Projects app contract upgrades, but so things are more clear going forward we will talk about Projects in I07.
Review May 2019 update**Progress: 30%**
Our Projects app currently interfaces with the StandardBounties contract developed by the Bounties Network, and they have recently released an upgraded version that will help enhance this initiative. We have started to analyze the new contract and plan to begin integration in June. This enhancement will provide support to this initiative as we extend the capabilities of the Projects app and eventually bring support for non-transferable tokens.
Review April 2019 updateThis is an initiative that expands upon our Planning Suite work by providing more features for reputation/merit based organizations, and we are in the process of planning the development timeline for the quasi-transferable token solution which is the core of this initiative.
This month we did develop a template for the Planning Suite and once we complete quasi-transferable tokens, it will be really easy to modify it to support the DAO Template aspect of this initiative.
Review March 2019 updateThere were no updates in March.
Review AGP-19Reputation System
Implementing a reputation system within Aragon will expand governance possibilities and allow the usage of Aragon for reputation-based governance without requiring the integration of external applications such as Colony or DAOstack which can add security risks.
The most logical place to implement the reputation system will be within the Projects application. To support reputation, changes to the Token Manager will be required, to allow minting a special type of quasi-transferable tokens that can be transferred only by a whitelist of addresses (e.g. the Standard Bounties contract or a specific Aragon application). Additionally, the Projects app will have to be enhanced to allow multiple tokens to be allocated to bounties.
The end goal is that when a user completes a task using the Projects app, they can collect a variety of tokens -- standard ERC-20s in addition to non-transferable reputation tokens.
At the moment, there are only two templates: Multisig and Democracy. To expand governance possibilities and allow for an easier user experience when a new DAO is being deployed, it will be beneficial to develop additional templates for the ecosystem. As part of this initiative we aim to create one additional template that will support reputation-based organizations.
I05 - Data Storage and Standards
Similar to contextual discussions, our goals with respect to storage this grant cycle have adjusted as we've learned more about what the community wants. There are two main findings: first, we learned that migrating off third party IPFS storage providers like Infura was a favorable initial step towards a more decentralized architecture. Second, Aragon teams and users need more sustainable and secure IPFS pinning architectures, so we put together a spec of what DAO tailored IPFS pinning solutions could look like. We feel like we're very close to accomplishing these goals.
During our offsite, we deployed our own IPFS node and are starting to host our user generated content and applications there. Soon we will no longer rely on any centralized service providers (but we may continue to back up copies of information there). We have updated all of our applications to use our IPFS node and are doing some more testing this week to ensure our node is stable.
Lastly, we have been working with the greater IPFS and Ethereum communities on an IPFS Pinning architecture for DAOs. We plan on formally publishing this spec this week, but if you're interested, here's a sneak peak. The spec is being continuously peer reviewed and refined, so if you have any feedback, please let us know! We are excited to build this architecture in our next AGP!
Review May 2019 update
There are no updates since last time. This work will be finalized in parallel to the discussions initiative as it is related.
Review April 2019 updateWe began to share research and ideas on the forum related to IPFS pinning and querying -- and this impacts three of our initiatives (I02, I03, I06) that rely heavily on user-generated data in different ways.
We wrote an overview of our research on OrbitDB, Textile and 3Box that will also be shared in a blog or forum format soon.
Our Flock proposal mentioned intermediate caching solutions, and hence we developed the beginnings of a backend REST API that pins files and metadata to IPFS and stores information in Mongo. The file adding, dag putting, pinning functionality, and Mongo storing are working. We’ve backseated this API for now as the discussions on IPFS Pinning solutions mature into an action plan.
Review March 2019 updateOur goal is to support Aragon discussion and profile applications with production level storage solutions for off-chain data by August 2019. Initially, we researched OrbitDB and go-textile — two distributed database solutions built on IPFS — to see if we could use their technology. We’re extremely excited about the potential of both of these projects, however, using either to build a production grade browser application in five months would require a significant amount of work on DevOps and private key management.
Generally speaking, we see two viable options — either leverage other technologies built on Orbit or textile that assume most of the risk, or build an infrastructure today that’s designed to scale into a fully distributed system later. For profiles, we think that 3box, an Ethereum profile API built on Orbit, will be the best solution. Not only does this seem to have Aragon community support, but it’s easy to use and we’re very close with their founding team in case any unexpected obstacles arise.
Review AGP-19Discussion forums, rich user profiles, and other familiar collaboration features are unique because they rely on data that is not efficiently stored on Ethereum. Our long term goal is to support these features with completely distributed storage while maintaining capabilities like optimal querying and dynamic access control. We’ll start with a “web 2.5” storage solution, learn more about users while relevant technologies mature, and remove intermediate services over time.
DAOs should be able to store their data with these qualities:
Accessible — all data from discussions and features alike will be available in distributed storage. This allows anyone to view and backup work without hitting a centralized server.
Standardized — by content addressing data and following open data standards, we can make people’s work more compatible across DAOs and other open source projects.
Timestamped — contributors should be able to create snapshots of their work across platforms. One way to do this is to store data on IPFS and write the hash to Ethereum.
Next 6 months - Immediate support for discussions and profiles
A near term storage solution preserves important qualities of decentralization without jeopardizing technical feasibility or user experience. It has a distributed data layer (i.e. IPFS) with intermediate services running on top of it. These services should be open source and provide clients efficient read/write capabilities to/from distributed storage.
Our initial architecture will likely have a distributed data store with intermediate services on top for caching, indexing, and writing to distributed storage. Although clients can always fetch data directly from distributed storage, our intermediate services will give enhanced access to it.
We’ll also be exploring how events relating to DAOs from centralized apps and Ethereum could be captured and displayed within Aragon apps. Some example events could include GitHub commits, issue comments, external forum discussion, etc.
Over time we can replace intermediate services with their distributed counterparts such as OrbitDB, BigChainDB, Threads, Solid and others. Part of our goal over the next six months will be to better understand the feasibility of using these technologies.
I06 - Organization Identity
We've taken our next steps towards allowing more settings to be saved at an organization level. To these end we've completed the aragon-storage application that will allow for the client to generate use case specific data. This is a "behind the scenes" application similar to the Vault, only instead of funds, it holds data. Long term this will allow us to save custom styles for organizations, but for now we are leveraging it to allow organizations to configure their default home application.
We've also completed complimentary work in the client so that this storage application can be saved to and read from as well as the specific work to allow for home the default home app to be set in the client.
Now that that dependency work was in place, we were able to bring the Home app MVP to close completion: the background worker integration with IPFS was completed, and an organization can set this new Home app to be the default (or any other app of their choice). We are still going through code reviews, testing, and minor cleanup but you should be able to run the code locally and check it out!
Review May 2019 update**Progress: 40% **
After sharing a design concept on the forum, we received feedback from Aragon One to go for a more simplified approach with respect to how the content is managed, yet to also provide flexibility for organizations to decide which app is their default "home app".
In order to allow for more organizational customization we have begun development on a storage module which we will integrate directly into the client. This will allow us to have dynamic access to decentralized assets with all of the benefits of the ACL.
Storage will be a contract-only application and is the technical building block that will enable DAOs to customize the existing Home app. While you could easily make Voting, Finance or your app of choice your home page, we hope many will opt to use our new Home app. Over time we will continue to leverage this new Storage module to allow users more control over Organizational Settings!
We have almost completed the MVP for our Home / About app, which currently includes a markdown editor and rendering. A few missing pieces are signing/saving data updates and some enhancements are still needed to the stylesheet.
Review April 2019 updateWhenever we initially proposed the Organization (DAO) Identity initiative we had described there would be an “About app” to manage various data blobs such as a manifesto, mission statement, etc. Although in the past month, we began to make the case that instead of a separate About app, that this should instead be the Home app.
We received buy-in from Aragon One on this high level strategy and in the past few weeks we have been starting to share design and technical research to receive buy-in for the ultimate implementation.
We delivered an initial design concept which presents a widget-based approach for customizing an organization’s homepage. In order to accomplish this, we need the ability to: pull individual application state into the client, store information about the home app, interpret information pulled from individual applications, and provide information back to individual applications. Refer to the technical architecture proposal for some initial ideas.
Review March 2019 updateThere were no updates in March.
Review AGP-19Organizations and entities have unique brands, which help them differentiate from one another and convey a fine-tuned message. One value add for the Aragon platform will be to provide features that allows an Organization to showcase their unique identity. At the moment, Organization avatars are the only way to differentiate. With the DAO Identity initiative, this will be expanded by allowing a DAO to tailor the branding and theme of the Aragon platform and also providing a user guide for self-hosted domains. To kickstart this, we will:
- Design at least three additional themes (including dark mode) and enhance the Organization Settings to support switching between themes
- Enhance the Organization Settings to support changing the background image (at the moment it’s an Eagle)
- Develop a simple read-only “About” Aragon App where the DAO can input and display their manifesto, mission statement, values, code of conduct, contact information
- Write a user guide for hack.aragon.org that describes how to deploy Aragon to a self-hosted domain
Eventually, the long-term goal for this initiative is to move toward a “Wordpress for DAOs” experience, with a rich library of themes and many ways to easily customize layouts. To support this ultimate vision, we will begin research to assess any architectural changes required.
I07 - Rewards Application and Open Enterprise
In preparation for our security audits, we have started to upgrade our contracts and also perform internal audits. We performed internal audits of our Address Book and Rewards contracts, and our security audit was kicked off on June 24th.
We upgraded Address Book so an Ethereum address is associated to an IPFS hash, which will allow organizations to eventually store more metadata besides a name and type. This upgrade will also make the Address Book more compatible with the Aragon IdentityBadge component down the line.
We are nearly complete with integrating the Projects app with the new StandardBounties contract and are now exposing features such as being able to cancel bounties at the contract level. Additionally, activity with Projects-funded bounties that occurs outside of Projects will now be captured, such as external fulfillments. Note that the frontend development is still pending for these new features, but we are aiming to republish Projects to Rinkeby soon™.
In July we will be finalizing the Projects, Allocations, and Dot Voting contract upgrades and handing them off to our security auditors.
Note: we have rebranded That Planning Suite to Open Enterprise, so this initiative has also been renamed.
Review May 2019 update**Progress: 70%**
In April, we reported our launch of That Planning Suite (TPS) onto Rinkeby which we feel is complete with respect to our original Nest proposal. But the Cross App UX initiative (I01) and the Expanding Governance initiatives (I04) are important dependencies needed for us to get v1 of TPS into a mainnet stage. To support the mainnet track, in May we performed QA for cross browser compatibility, made progress on end to end testing, and addressed bugs reported by alpha users. In June we will be performing our internal audit and begin integrating enhancements.
What we weren't prepared for is our alpha users immediately using our Rinkeby apps for real DAO operations! The Aragon Mesh team has been paying bounties on mainnet after a ticket is completed in Rinkeby. 😍😍😍 1Hive is another related organization that has started to use TPS on Rinkeby for operations as well and we are even featured on their homepage! We have been addressing bugs they have found and are also starting to prioritize their feature requests for our next AGP.
For our progress meter, we will mark this initiative as 90% once all apps have been handed off for a security audit. Hence the 20% between there is addressing feature requests, bugs, and enhancements taking up new components we are developing.
Review April 2019 updateRewards Last month we were in the middle of the application development for the Rewards application, with the integration between the front-end and smart contracts remaining, and this month we completed the development.
Reward distributions can now be created using an snapshottable reference token that conforms to the Minime function signature. Rewards can also be created and calculate retroactively (so long as they don’t predate the creation of the reference token).
We completed making all of our applications responsive. We got fully acquainted with the process of publishing applications and updated our application manifests to conform to the new app center standards with screenshots, simple descriptions and icons that are complementary to the other Aragon core apps.
We launched That Planning Suite on Rinkeby and created a demo Dune DAO that comes with our apps installed.
We developed a template to create a Planning Suite DAO, basing it off the Democracy and Beta Base templates, and also integrated it with a frontend to make it really easy for people create a Planning Suite DAO without touching the cli. This resulted in us spinning up a server to host a version of the client at rinkeby.autark.xyz. We did also create a guide for people that are interested in installing the apps individually via the cli.
While we are on Rinkeby now, there is always room for improvement. Our next steps are to finish implementing end to end testing, perform QA for cross browser compatibility, address bugs reported by alpha users, perform a thorough internal code review and audit, lock down our contracts so we can then hand it off for an external security audit, and make adjustments as necessary for our mainnet release.
Review March 2019 updateThat Planning Suite (TPS) is a suite of aragonOS apps that allow DAOs to curate issues, collectively budget, and design custom reward & bounty programs.
We began the development of the suite as part of the Nest program where the work was divided into five milestones. As mentioned in our Flock proposal, the plan was to roll up Milestones 4–5 into Flock. To provide some additional context, Milestones 1–3 included the following apps: Range Voting, Address Book, Allocations, and Projects. Milestones 4–5 includes the development of the Rewards app in addition to fine-tuning the entire suite — and these milestones have been one of our primary development efforts in our first five weeks as a Flock team.
For the Rewards app: we completed the smart contract work and the front-ends, and have began integrating the two.
As far as the “fine-tuning” of TPS, we have:
- Implemented Cypress for end-to-end testing
- Implemented the store to handle concurrent events
- Integrated various aragon-ui components to make consistent with existing Aragon apps
- Began the work to make TPS mobile-friendly / responsive
- Addressed various code review comments from Aragon One from our previous milestone reviews
- We are on track for deploying That Planning Suite to Rinkeby by mid-April.
Review AGP-19This Flock proposal includes team members that were awarded a Nest grant for a Planning Suite, which contains five applications: Allocations, Range Voting, Address Book, Projects, Rewards.
The plan is to finish Milestone 3 by the end of January, before the Flock funding would begin. This Flock proposal includes rolling up Milestone 4 and 5 into Flock which entails the Rewards app, and any final “clean up” to get the Planning Suite into a stage to launch. Since we are rolling up Milestone 4 and 5 into this proposal, that means that we will not get paid those additional milestones which value to $40,000. Instead, the team will be paid via Flock payroll.
Since the completion of the Planning Suite overlaps with the timeline of this Flock proposal, we think it makes sense to roll up the remaining work as it will be delivered more expediently with more full-time team members.
June 2019 Spending Report
June 1, 2019 — June 30, 2019
- USD: 45,110
- EUR: 116,310 (129,644 USD)
Total: $174,754 USD
- Autark Payroll (2 pay periods): $51,751
- Open Work Labs Payroll (2 pay periods): $10,000
- Contractors (Accounting, Design, Recruiting): $6,363
- Offsite: $2,224 (partial spending, previous costs occurred last month)
- Co-working space memberships: $526
- Software: $448
- Misc. Transaction/Conversion Fees: $152
Total: $71,464 USD
Based on our accounts:
- USD: 29,305
- EUR: 67,856 (75,591 USD)
Total: $104,896 USD
Verify: $174,754 (previous balance) - $71,464 (costs) = $103,290 USD
We have more in our bank than expected, and I think this is due to the fluctuation in the value of Euro. We haven't had time to fully reconcile, but hey - having more money than you thought is good!