Skip to content

Instantly share code, notes, and snippets.

View pgebheim's full-sized avatar

Paul Gebheim pgebheim

  • San Francisco, CA
View GitHub Profile
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
ragma solidity 0.5.15;
pragma experimental ABIEncoderV2;
import "ROOT/trading/wrappedShareToken/WrappedShareToken.sol";
import 'ROOT/para/interfaces/IParaShareToken.sol';
import 'ROOT/libraries/TokenId.sol';
/**
* @dev This is a factory that creates Wrappers around ERC1155 shareTokens generated by Augur
* @author yashnaman
@pgebheim
pgebheim / layer2-spec.md
Last active October 21, 2020 05:14
Augur Sidechain Specification

Augur Trading on L2 Specification

Goal

The security of the Augur v2 Oracle was designed to be independent of trading, so long as sufficient trading fees can be extracted such that the total REP market cap grows to be able to maintain security of the oracle via Augur's forking mechanism. Because of this design decision it is possible to moving Augur v2 Trading off of Layer 1 (ethereum) and on to any other plaform under the constrain that the assets used for trading must be locked up on ethereum when participating.

Also, since releasing Augur v2, work has been done to implement support for multiple collateral types in Augur. This feature is referred to as "ParaAugur", meaning Parallel Augur. This implementation allows multiple trading implementations, collateralized in arbitrary tokens, to pool their Open Interest such that the security guarantees above remain true. This opens the opportunity for side-chains to interact with a specific collateralization of Augur depending on their use case, and also open

0x

I'm seeing a LOT of errors where by browser cannot connect to servers?

If your browser is attempting to connect to IP addresses on port 60559 -- this is a part of the Gnosis 0x mesh Peer to Peer network. Generally speaking these issues are benign unless you are specifically looking into what two peers cannot communicate.

  • It is normal to see a lot of errors *

But why is it trying to connect to localhost:60559 / 127.0.0.1:60559

So when you connect to the mesh, your browser will reach out to one of the bootstrap nodes that is in the default list. This node will then pass part of its current list of peers back to your browser, which will initiate trying to connect to them directly. The addresses of these nodes are determined by what each peer believes its address to be, and can be a mix of internal (127.0.0.1, 192.168.x.x, 10.0.0.x) and public addresses. These may not allow connections. There is an optimization that would try to ignore local addresses when not in dev mode that should happen

hello
// this was basically copied directly from the ipfs documentation
const validCID = 'QmQ2r6iMNpky5f1m4cnm3Yqw8VSvjuKpTcK1X7dBR1LkJF' // await loadIpfsHashFromGithub();
const stream = ipfs.getReadableStream(validCID)
pull(
stream,
pull.collect((err, files) => {
if (err) {
<html>
<head>
<script>
(async function() {
const root = "/ipfs/QmUXswSSMxd6oZyT7ViCo6KGLraVgiYZ3jtctp34bKEF2F/?ethereum_node_http=https%3a%2f%2feth-mainnet.alchemyapi.io%2fjsonrpc%2f7sE1TzCIRIQA3NJPD5wg7YRiVjhxuWAE&augur_node=wss%3a%2f%2ftheaugurnode.com%2faugur-node#!/markets";
const data = await fetch(root);
const el = document.createElement('html');
el.innerHTML = await data.text();
window.resEl = el;
async setHighestSyncBlock(dbName: string, blockNumber: number, syncing: boolean, rollback = false): Promise<PouchDB.UpsertResponse> {
// NOTE: dbName, in this case, is actually the id of the record in the SyncStatus db.
return this.db.upsert(dbName, (document: SyncDocument) => {
// make sure the truly highest block is always being used
document.blockNumber = rollback ? blockNumber : Math.max(blockNumber, document.blockNumber);
document.syncing = syncing;
// db.upsert sets _rev and _id so we don't have to
return document;
});

Proposal:

Extend Query Schema to support grouping by topics and returning FIRST N or LAST N logs from the group.

Example Schema:

The follow example GraphQL schema addition would support all necessary operations for this grouped-selection proposal. Other schema formulations may do the the same, so another may work as well or better than this example.

type GroupedLogs {
 groupTopics: [Bytes32!]!
type SubscriptionKey = string;
interface Connector {
trackAccount(account:string);
};
interface EventEmitter {
emit(key, payload);
subscribe():SubscriptionKey