SignReliably

This project allows users to secure, optionally store, and endorse records such as contracts they have agreed to.
Examples of the contract use case include a residential lease. When an issue happens, some dishonest parties could try to change the terms of the contract and attempt to enforce their modified version in court, wasting the Court's time over a dispute around what the terms of the agreement actually were, which usually comes down to a credibility question. On the whole, this type of misrepresentation tends to further disadvantage honest members of historically disadvantaged groups.
Ink signatures do not do a good job of defending against such attacks, but digital signatures used in a document endorsement (e.g. through this application) can do much, much better.
SignReliably helps parties keep track of exactly what they agreed to, should they need to prove it later on, helping keep parties honest and helping trustworthy parties signal their trustworthiness by agreeing to provably commit to the exact terms of an agreement.
Leases are just the tip of the iceberg: founders' agreements or incorporation documents are relevant examples in this hackathon context.
Open letters, petitions, and agreements like the Crypto Climate Accord could be made more secure and trustworthy with this technology.
Optional POAP integration facilitates celebration of particularly important agreements.
As an example use case outside contracts, consider airworthiness forms for aircraft parts - a manufacturer or repair station may attest to most of the information on the form, but a regulator-licensed inspector also has to sign off. Status quo systems generally leave room for fraud and for modifications where there may be incentives to do so, and a blockchain-secured digitization could help reduce a LOT of labor costs associated with transfers.
Endorsement and peer review of scientific papers and similar works is another potential use case, plugging into a larger platform that tracks a citation graph etc.
You can think of this application as similar to Docusign and its competitors, but more secure.
See more in response to this question on the "use cases" page of the application (or read the HTML page in the repo for the content).

The project is written mostly in TypeScript (with an HTML + CSS front-end), in an iterative (agile) fashion, adding features and incorporating sponsor technologies over the course of the hackathon. Most of the hackathon was spent struggling with TableLand, which actually doesn't support smart contracts being able to read data and has a lot of issues trying to create tables from smart contracts, with little diagnosis help about why. Server-side use of the SDK for table creation also led to Node reports of some errors in TableLand or its dependencies. I spent a day verifying and reporting an issue with clear steps to reproduce and might do something similar with other issues after the hackathon, but a good bug report is a lot of work, limiting the number of those I could spend time doing during the hackathon.
I finally succeeded in table creation with a workaround of adding some admin functions that create the table in-browser when an admin runs the first test setup after contract deployment, then grants permissions to the smart contract, and then updates the smart contract with pointers to the tables, and storing data in the smart contract where SELECT statements would otherwise be required for atomic on-chain transactions. I also ran into issues in the smart contract development related to Solidity's pretty low limit on local variables and contract size, and wound up splitting the contract into a stateful main contract and a stateless helper contract. Tableland's demo of EVN interaction, given during the hackathon, used a CanvasGame example with ERC721 NFTs allowing transferrable ownership of certain control rights, which seemed like a very useful feature to include, and I did include it, though the mechanics of NFT transfer will have to go through tools and platforms others have built at least for now. However, I found a common edge case in which the first table row created gets an id of 0 and this is treated as an invalid token id for the purpose of checking ERC721 ownership. The solution to this was to adapt the constructor of the smart contract to just skip over that first row id. That might get written up as an issue report after further post-hackathon work and minimal example verification.
In this project in general, UI for a feature or option was generally written first, to set clear expectations about what the system should do and to facilitate manual testing of distributed/backend components.
Then, distributed/backend features were added to support the UI and get the functionality basically working, and then efforts turned to enhancing decentralization and incorporating more sponsor technologies.
In some cases, the Node.js backend exists primarily to protect API keys, noting e.g. on Estuary's page this text about how "It is important you understand how to protect your API key/secrets from bad actors and abuse." It's disappointing to see that I spent (from a competitive standpoint, wasted?) so much time on this requirement to protect API keys while competitors are just putting it in the browser which is so much easier from a technical perspective but seems noncompliant with sponsor and event rules as I understood them. Overall, I think the project was well-scoped for a hackathon like this, with a heavily outsize potential for impact.
As is not unusual with software development, it was a few blockers that took up most of the time but otherwise the solution could likely have been much more well-developed by the submission deadline.
I did not have experience using Hardhat for smart contracts deployment prior to this hackathon, but decided to try it out as new and potentially helpful technologies (as I was doing with various sponsor technologies already). This also helped with more closely tracking examples and minimizing suspects of why things weren't working when they failed. I was a bit surprised to see that Hardhat doesn't seem to store deployment information in with the contract data like Truffle does, to facilitate the in-browser contract instance connection. (It's possbile this functionality's there, but I just couldn't figure it out sufficiently quickly.) I wound up building a solution for that which can be found in the repo at source/customContracts/deployScripts/deployTracker.ts, with output currently located at deployedLocations.json in the same folder. This little JSON file is loaded by the browser to figure out where to connect to a contract, updated dynamically on redeployment. In conjunction with how the deployTracker is used (in deploy.ts), it also works to prevent redeployment of the exact same contract (measured by bytecode hash matching) in cases where, for example, the stateful main contract got updated but the stateless helper contract did not need redeployment.